On 2016/08/22 13:51, Ashutosh Bapat wrote: > The parent-child relationship of multi-level partitioned tables is not > retained when creating the AppendRelInfo nodes. We create RelOptInfo nodes > for all the leaf and intermediate tables. The AppendRelInfo nodes created > for these RelOptInfos set the topmost table as the parent of all the leaf > and child tables. Since partitioning scheme/s at each level is/are > associated with the parent/s at that level, we loose information about the > immediate parents and thus it becomes difficult to identify which leaf node > falls where in the partition hierarchy. This stops us from doing any > lump-sum partition pruning where we can eliminate all the partitions under > a given parent-partition if that parent-partition gets pruned. It also > restricts partition-wise join technique from being applied to partial > partition hierarchy when the whole partitioning scheme of joining tables > does not match. Maintaining a RelOptInfo hierarchy should not create > corresponding Append (all kinds) plan hierarchy since > accumulate_append_subpath() flattens any such hierarchy while creating > paths. Can you please consider this point in your upcoming patch?
I agree. So there seem to be two things here: a) when expanding a partitioned table inheritance set, do it recursively such that resulting AppendRelInfos preserve *immediate* parent-child relationship info. b) when accumulating append subpaths, do not flatten a subpath that is itself an append when ((AppendPath *) subpath)->path.parent is a RelOptInfo with non-NULL partitioning info. Is the latter somehow necessary for pairwise-join considerations? I think I can manage to squeeze in (a) in the next version patch and will also start working on (b), mainly the part about RelOptInfo getting some partitioning info. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
