Re: print_path is missing GatherMerge and CustomScan support

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

In response to

Responses

Browse pgsql-hackers by date

  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