Re: Should we add GUCs to allow partition pruning to be disabled?
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-05-10T16:50:25Z
Lists: pgsql-hackers
On Thu, May 10, 2018 at 8:57 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > b) by default, no partitions are > scanned, and we examine the query to determine which ones must be > scanned. > There is an element of logic that says "by default, no partitions are scanned" is not a reasonable behavior mode. Thus an alternative analogy would be: Bucket A is the set of all relevant partitions in the tree Pruning: remove from bucket A those which we know we can skip; then iterate over A Selection: choose those items from A that are possible holders of our data and process each one (place all selected items into bucket B and iterate over B if you want to perform selection in total first). As a user I don't really need to know which model is implemented and the name doesn't necessarily imply the implementation. Pruning seems to be the commonly-used term for this feature and we should stick with that. David J.
Commits
-
Tweak partitioning documentation wording
- 12b9affb32a6 11.0 landed
-
docs: Rework sections on partition pruning/exclusion
- bebc46931a12 11.0 landed
-
Add GUC enable_partition_pruning
- 055fb8d33da6 11.0 landed