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