On 20 July 2018 at 21:44, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> But I don't think the result of make_partition_pruneinfo itself has to be
> List of PartitionedRelPruneInfo nested under PartitionPruneInfo. I gather
> that each PartitionPruneInfo corresponds to each root partitioned table
> and a PartitionedRelPruneInfo contains the actual pruning information,
> which is created for every partitioned table (non-leaf tables), including
> the root tables. I don't think such nesting is necessary. I think that
> just like flattened partitioned_rels list, we should put flattened list of
> PartitionedRelPruneInfo into the Append or MergeAppend plan. No need for
> nesting PartitionedRelPruneInfo under PartitionPruneInfo.
To do that properly you'd need to mark the target partitioned table of
each hierarchy. Your test of pg_class.relispartition is not going to
work as you're assuming the query is always going to the root. The
user might query some intermediate partitioned table (which will have
relispartition = true). Your patch will fall flat in that case.
You could work around that by having some array that points to the
target partitioned table of each hierarchy, but I don't see why that's
better than having the additional struct. There's also some code
inside ExecFindInitialMatchingSubPlans() which does a backward scan
over the partitions. This must process children before their parents.
Unsure how well that's going to work if we start mixing the
hierarchies. I'm sure it can be made to work providing each hierarchy
is stored together consecutively in the array, but it just seems
pretty fragile to me. That code is already pretty hard to follow.
What's the reason you don't like the additional level to represent
multiple hierarchies?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services