On Tue, Nov 14, 2017 at 10:30 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Nov 11, 2017 at 10:48 PM, Thomas Munro > <thomas.mu...@enterprisedb.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
parallel-leader-participation-v2.patch
Description: Binary data