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

On Sun, Nov 12, 2017 at 8:51 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sun, Nov 12, 2017 at 9:18 AM, 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.
>>
>> I'm not sure why node->need_to_rescan is initialised by both
>> ExecGatherInit() and ExecGather(). Only the latter's value matters,
>> right?
>>
>
> I don't see anything like need_to_rescan in the GatherState node. Do
> you intend to say need_to_scan_locally? If yes, then I think whatever
> you said is right.

Right, that's what I meant to write. Thanks.

>> I've added this to the January Commitfest.
>>
>
> +1 to this idea. Do you think such an option at table level can be
> meaningful? We have a parallel_workers as a storage option for
> tables, so users might want leader to participate in parallelism only
> for some of the tables.

I'm not sure. I think the reason for turning it off (other than
developer testing) would be that the leader is getting tied up doing
work that takes a long time (sorting, hashing, aggregating) and that's
causing the workers to be blocked because their output queue is full.
I think that type of behaviour comes from certain plan types, and it
probably wouldn't make sense to associate this behaviour with the
tables you're scanning.

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