On Tue, Sep 5, 2017 at 11:54 AM, Amit Langote
<Langote_Amit_f8@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