On 18/03/2016 00:56, Tom Lane wrote:
> 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.
>
Oh, I wasn't aware of that, thanks for the pointer.
> 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
>
I just saw that it's already documented that way. I attach a patch that
makes sure we don't try to compute a parallel_degree beyond this limit
(if you think it's worth it), and a missing description and "change
requires restart" for the max_worker_processes parameter in
postgresql.conf.sample.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org