Re: Choosing parallel_degree - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Choosing parallel_degree
Date
Msg-id 17487.1458259018@sss.pgh.pa.us
Whole thread Raw
In response to Re: Choosing parallel_degree  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Responses Re: Choosing parallel_degree
List 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 by date:

Previous
From: Marisa Emerson
Date:
Subject: Re: Proposal: BSD Authentication support
Next
From: Chapman Flack
Date:
Subject: Re: Make primnodes.h gender neutral