Re: Parallel Append can break run-time partition pruning

On Fri, 17 Apr 2020 at 19:08, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> While looking at this, I observed that the PartitionPruneInfo of the
> top-level Append (the one that later gets thrown out) contains bogus
> information:
>
> {PARTITIONPRUNEINFO
> :prune_infos ((
> {PARTITIONEDRELPRUNEINFO
> :rtindex 1
> :present_parts (b 0)
> :nparts 1
> :subplan_map 0
> :subpart_map 1
>
> One of these should be -1.
>
> {PARTITIONEDRELPRUNEINFO
> :rtindex 2
> :present_parts (b)
> :nparts 2
> :subplan_map -1 -1
> :subpart_map -1 -1
>
> subplan_map values are not correct, because subpaths list that would
> have been passed would not include paths of lower-level partitions as
> the flattening didn't occur.

It's not great that we're generating that, but as far as I can see,
it's not going to cause any misbehaviour. It'll cause a small
slowdown in run-time pruning due to perhaps having to perform an
additional call to find_matching_subplans_recurse() during execution.
In this case, it'll never find any subnodes that match due to both
maps having all -1 element values.

Since f2343653f5, we're not using partitioned_rels for anything else,
so we should likely fix this so that we don't add the item to
partitioned_rels when we don't pullup the sub-Append. I think we
should hold off on fixing that until we decide if any adjustments need
to be made to the sub-Append pullup code.

David