From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: print_path is missing GatherMerge and CustomScan support |
Date: | 2018-07-27 06:40:48 |
Message-ID: | 5B5ABE70.40606@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2018/07/27 4:50), Robert Haas wrote:
> On Thu, Jul 26, 2018 at 1:14 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> because we currently don't consider gathering partial child-scan or
>> child-join paths. I think we might consider that in future, though.
>
> You generally want to put the Gather node as high up in the plan tree
> as possible. I think the only case in which this is beneficial is if
> you can't put the Gather or Gather Merge node above the Append because
> only some of the children are parallel-safe. In that case, a separate
> Gather per child can be better than no parallelism at all. It's a
> rare case, but it can happen. Actually, I thought we had code for this
> already: see the end of apply_scanjoin_target_to_paths().
Agreed. Thanks for the explanation!
(I think that at least currently, there is no need for the Gather and
GatherMerge cases in reparameterize_path_by_child, but I don't object to
keeping those as-is there.)
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-27 07:02:32 | Re: print_path is missing GatherMerge and CustomScan support |
Previous Message | Michael Paquier | 2018-07-27 06:28:40 | Re: Temporary tables prevent autovacuum, leading to XID wraparound |