From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Removing [Merge]Append nodes which contain a single subpath |
Date: | 2017-10-26 11:37:48 |
Message-ID: | CAKJS1f-hVBSNL-TNQ2nq3n+aDCdOMVp32QRm85owUkaRP=hw0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 October 2017 at 23:42, Antonin Houska <ah(at)cybertec(dot)at> wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>
>> Method 1:
>>
>> In set_append_rel_size() detect when just a single subpath would be
>> added to the Append path.
>
> I spent some time reviewing the partition-wise join patch during the last CF
> and have an impression that set_append_rel_size() is called too early to find
> out how many child paths will eventually exist if Append represents a join of
> a partitioned table. I think the partition matching takes place at later stage
> and that determines the actual number of partitions, and therefore the number
> of Append subpaths.
I understand that we must wait until set_append_rel_size() is being
called on the RELOPT_BASEREL since partitions may themselves be
partitioned tables and we'll only know what's left after we've
recursively checked all partitions of the baserel.
I've not studied the partition-wise join code yet, but if we've
eliminated all but one partition in set_append_rel_size() then I
imagine we'd just need to ensure partition-wise join is not attempted
since we'd be joining directly to the only partition anyway.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-26 11:38:53 | Re: make async slave to wait for lsn to be replayed |
Previous Message | Robert Haas | 2017-10-26 11:35:25 | Re: legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function |