On 20 July 2018 at 21:44, Amit Langote <langote_amit...@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