On Tue, Sep 5, 2017 at 11:54 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/05 13:20, Amit Langote wrote: >> The later phase can >> build that list from the AppendRelInfos that you mention we now [1] build. >> >> [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=30833ba154 > > Looking at that commit again, AppendRelInfos are still not created for > partitioned child tables. Looking at the code in > expand_single_inheritance_child(), which exists as of 30833ba154: > > > /* > * Build an AppendRelInfo for this parent and child, unless the child is a > * partitioned table. > */ > if (childrte->relkind != RELKIND_PARTITIONED_TABLE && !childrte->inh) > { > ...code that builds AppendRelInfo... > } > else > *partitioned_child_rels = lappend_int(*partitioned_child_rels, > childRTindex); > > you can see that an AppendRelInfo won't get built for partitioned child > tables. > > Also, even if the commit changed things so that the child RT entries (and > AppendRelInfos) now get built in an order determined by depth-first > traversal of the partition tree, the same original parent RT index is used > to mark all AppendRelInfos, so the expansion essentially flattens the > hierarchy. In the updated patch I will post on the "path toward faster > partition pruning" thread [1], I am planning to rejigger things so that > two things start to happen: > > 1. For partitioned child tables, build the child RT entry with inh = true > and also build an AppendRelInfos > > 2. When recursively expanding a partitioned child table in > expand_partitioned_rtentry(), pass its new RT index as the > parentRTindex to the recursive call of expand_partitioned_rtentry(), so > that the resulting AppendRelInfos reflect immediate parent-child > relationship > > With 1 in place, build_simple_rel() will build RelOptInfos even for > partitioned child tables, so that for each one, we can recursively build > an Append path. So, instead of just one Append path for the root > partitioned table, there is one for each partitioned table in the tree. > > I will be including the above described change in the partition-pruning > patch, because the other code in that patch relies on the same and I know > Ashuotsh has wanted that for a long time. :)
Those changes are already part of my updated 0001 patch. Aren't they? May be you should just review those and see if those are suitable for you? -- 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
