Re: Problem with default partition pruning
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
yuzuko <yuzukohosoya@gmail.com>, shawn wang <shawn.wang.pg@gmail.com>, Shawn Wang <shawn.wang@highgo.ca>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-08-08T08:08:51Z
Lists: pgsql-hackers
Hi Simon, On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Well, yes, avoiding that is the point of this commit also: we were >> scanning some partitions for some queries, after this patch we're >> supposed not to. > > > Understood > > My concern was about the additional execution time caused when there would be no benefit, especially if the algoithmic cost is O(N) or similar (i.e. worse than O(k)) Note that we apply constraint exclusion only to the (sub-partitioned) parent, not to all partitions, so the cost is not O(N) in the number of partitions. The idea is that if the parent is excluded, all of its partitions are. We normally wouldn't need to use constrain exclusion, because partition pruning can handle most cases. What partition pruning can't handle sufficiently well though is the case where a clause set that contradicts the partition constraint is specified -- while all non-default partitions are correctly pruned, the default partition is not. Using constraint exclusion is a workaround for that deficiency of the partition pruning logic. Thanks, Amit
Commits
-
Don't constraint-exclude partitioned tables as much
- 815ef2f568c7 13.0 landed
-
Apply constraint exclusion more generally in partitioning
- 4e85642d935e 13.0 landed
-
Improve pruning of a default partition
- e3967a16d3a0 11.5 landed
- 86544071484a 12.0 landed
- 489247b0e615 13.0 landed
-
Doc: Fix event trigger firing table
- 44460d7017cd 13.0 cited
-
Remove obsolete nbtree insertion comment.
- 489e431ba56b 12.0 cited