Re: [HACKERS] A GUC to prevent leader processes from running subplans?

On Sat, Nov 11, 2017 at 10:48 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> How about parallel_leader_participation = on|off? The attached
> version has it that way, and adds regression tests to exercise on, off
> and off-but-couldn't-start-any-workers for both kinds of gather node.

This looks mostly fine to me, but I think the documentation is strange:

+ Allows the leader process to execute the query plan under
+ <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
+ instead of waiting for worker processes. The default is
+ <literal>on</literal>. Setting this value to <literal>on</literal>
+ can cause the leader process to begin producing tuples sooner instead
+ of waiting for worker processes to start up, but might in some cases
+ also cause workers to become blocked waiting for the leader to clear
+ tuple queues.

This documentation would seem exactly right to me if the default value
were off, but as it is it seems kinda backwards, because it's
explaining why you might want to set the value to what is anyway the
default. Also, it's always possible for the workers to become blocked
waiting for the leader, regardless of how this GUC is set. It becomes
more likely when this turned off, but that's not quite the same thing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company