On Mon, Jul 14, 2025, at 2:41 PM, Tom Lane wrote:
> "Scott Mead" <scott@meads.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_costthat makes good decisions about parallelism on a user's behalf. I believe that setting the
SIGHUP-ablemax_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 guess my hang-up is that max_parallel_workers_per_gather was enabled for testing and left on without discussion.
ISTMthat it was accidentally enabled for regression purposes and we just forgot to flip it off before shipping.
The other issue is that when you have a nonzero max_parallel_workers_per_gather, Postgres tries to launch parallel
workersand if you've exhausted max_parallel_workers, it falls back to a standard plan. There's no good way for a user
toreally understand the behavior here, and having max_parallel_worker_per_gather enabled adds overhead across the
entirecluster.
>
> 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.
I guess my point is that max_parallel_workers_per_gather and parallel_setup_cost are effectively the same hammer,
they'reboth dynamic and configurable per-session. The *_cost parameters are a bit complicated for many users to
understandwhereas setting a max to 0 has a very clear meaning.
> 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.)
Other than picking an arbitrary value (i.e. 5000), any thoughts about how to build a case around a specific value ?
>
> BTW, I would say largely the same things about JIT, but I suppose
> that had better be a separate thread.
Agreed :)
>
> regards, tom lane
>
--
Scott Mead
scott@meads.us
