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

On Tue, Nov 14, 2017 at 10:30 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

Thanks. You're right. Rebased and updated to describe what "off" does.

--
Thomas Munro
http://www.enterprisedb.com