Re: simple patch for discussion

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Greg Hennessy <greg(dot)hennessy(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: simple patch for discussion
Date: 2025-07-17 17:03:25
Message-ID: zf4uvkvvmwnbd5s6q2jp5mb6uh5vlqpnrzepd4okfuum3sckuv@psblck2vhlwe
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-07-17 15:01:55 +1200, David Rowley wrote:
> On Thu, 17 Jul 2025 at 12:44, Greg Hennessy <greg(dot)hennessy(at)gmail(dot)com> wrote:
> > workers, but there isn't an easy way to get more
> > workers.
>
> Is "alter table ... set (parallel_workers=N);" not easy enough?

I don't think that's a great approach, as that basically means the user has to
do all the computation for how many workers are a good idea
themselves. Manually setting it obviously doesn't deal with future growth etc.

Right now we basically assume that the benefit of parallelism reduces
substantially with every additional parallel worker, but for things like
seqscans that's really not true. I've seen reasonably-close-to-linear
scalability for parallel seqscans up to 48 workers (the CPUs in the system I
tested on). Given that our degree-of-parallelism logic doesn't really make
sense.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-17 17:04:36 Re: pg_dump does not dump domain not-null constraint's comments
Previous Message Tom Lane 2025-07-17 16:58:36 Re: Fix PQport to never return NULL if the connection is valid