On Fri, Aug 18, 2017 at 10:12 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote > >>> 0002: Teach expand_inherited_rtentry to use partition bound order >> >> 0004 in [1] expands a multi-level partition hierarchy into similar >> inheritance hierarchy. That patch doesn't need all OIDs in one go. It >> will have to handle the partition hierarchy level by level, so most of >> the code added by this patch will need to be changed by that patch. Is >> there a way we can somehow change this patch so that the delta in 0004 >> is reduced? That may need rethinking about using >> RelationGetPartitionDispatchInfo(). > > Regarding that, I have a question: > > Does the multi-level partition-wise join planning logic depend on the > inheritance itself to be expanded in a multi-level aware manner. That is, > expanding the partitioned table inheritance in multi-level aware manner in > expan_inherited_rtentry()?
Yes, it needs AppendRelInfos to retain the parent-child relationship. Please refer [1], [2], [3] for details. > > Wouldn't it suffice to just have the resulting Append paths be nested per > multi-level partitioning hierarchy? We are joining RelOptInfos, so those need to be nested. For those to be nested, we need AppendRelInfos to preserve parent-child relationship. Nesting paths doesn't help. Append paths actually should be flattened out to avoid any extra time consumed in nested Append node. [1] https://www.postgresql.org/message-id/cafjfprcemmx26653xfayvc5kvqcrzckscvfqzdbxv%3dkb8ak...@mail.gmail.com [2] https://www.postgresql.org/message-id/CAFjFpRefs5ZMnxQ2vP9v5zOtWtNPuiMYc01sb1SWjCOB1CT=u...@mail.gmail.com [3] https://www.postgresql.org/message-id/CAFjFpRd6Kzx6Xn%3D7vdwwnh6rEw2VEgo--iPdhV%2BFb7bHfPzsbw%40mail.gmail.com -- 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
