On Sun, Nov 12, 2017 at 8:51 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Sun, Nov 12, 2017 at 9:18 AM, Thomas Munro
> <thomas.munro@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.
>>
>> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
