Re: Disable parallel query by default
От | Tom Lane |
---|---|
Тема | Re: Disable parallel query by default |
Дата | |
Msg-id | 709210.1752518509@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Disable parallel query by default ("Scott Mead" <scott@meads.us>) |
Ответы |
Re: Disable parallel query by default
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: