Re: Parallel Append can break run-time partition pruning

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Robert Haas <robert(dot)haas(at)enterprisedb(dot)com>, amitdkhan(dot)pg(at)gmail(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallel Append can break run-time partition pruning
Date: 2020-04-19 23:00:04
Message-ID: CAApHDvqQbRKYHgB2UHzeEAStvDAE_FOfoLsEEZb6ZK7URW5FmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-04-19 23:02:08 Re: PG compilation error with Visual Studio 2015/2017/2019
Previous Message Michael Paquier 2020-04-19 22:55:46 Re: Adding missing object access hook invocations