Re: Disable parallel query by default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Scott Mead" <scott(at)meads(dot)us>
Cc: "Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at>, "Greg Sabino Mullane" <htamfids(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Disable parallel query by default
Date: 2025-07-14 18:41:49
Message-ID: 709210.1752518509@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Scott Mead" <scott(at)meads(dot)us> writes:
> I'd like to re-open the discussion for this commitfest item. I still have not been able to find a value for parallel_setup_cost that makes good decisions about parallelism on a user's behalf. I believe that setting the SIGHUP-able max_parallel_workers_per_gather to 0 by default is still the best way to prevent runaway parallel execution behavior.

I still think that proposal has no chance of getting off the ground.

I do agree that the current default cost settings for parallel query
are over-optimistic and allow us to choose PQ when we shouldn't.
But the answer to that is to improve the cost estimation, not to
swing a bigger hammer at it. If changing parallel_setup_cost doesn't
get the job done, maybe there is some deeper problem in the way we
estimate the costs of using parallelism. (One thought that occurs
to me is that we don't model the impact of the parallel worker pool
being shared across sessions, but maybe that's a big chunk of the
issue.)

BTW, I would say largely the same things about JIT, but I suppose
that had better be a separate thread.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-07-14 18:43:31 Re: pg_dump does not dump domain not-null constraint's comments
Previous Message Andres Freund 2025-07-14 18:36:49 Re: AIO v2.5