Re: Choosing parallel_degree

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Choosing parallel_degree
Дата
Msg-id 17487.1458259018@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Choosing parallel_degree  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Ответы Re: Choosing parallel_degree  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Список pgsql-hackers
Julien Rouhaud <julien.rouhaud@dalibo.com> writes:
> Shouldn't we also check "parallel_degree < max_worker_process" ?

> There's no need to compute any further than that. I think the best fix
> would be to add a CheckHook or AssignHook on max_parallel_degree GUC to
> make sure it's not more than max_worker_process.

Please, let's not go there.  Interdependent checks on GUC values are far
harder to get right than you think.  It's far better to design the GUC
specifications so that it doesn't matter.

For an example whereof I speak, check the sordid history of commit
ee1e5662d8d83307 ("Auto-tune effective_cache size to be 4x shared
buffers"), which eventually got reverted after a huge amount of thrashing
trying to make it work consistently.  Admittedly, that was trying to make
the default value of GUC X depend on GUC Y, but I think checking whether
X <= Y would have many of the same problems.  The core issue is you don't
know which one's going to get set first.

In this particular case I think it'd be fine to document that the
effective amount of parallelism is Min(parallel_degree,max_worker_process).
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marisa Emerson
Дата:
Сообщение: Re: Proposal: BSD Authentication support
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Make primnodes.h gender neutral