| 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
| 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 |