On Thu, Oct 26, 2017 at 5:07 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 26 October 2017 at 23:42, Antonin Houska <a...@cybertec.at> wrote: >> David Rowley <david.row...@2ndquadrant.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. >
I think Antonin has a point. The join processing may deem some base relations dummy (See populate_joinrel_with_paths()). So an Append relation which had multiple child alive at the end of set_append_rel_size() might ultimately have only one child after partition-wise join has worked on it. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
