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

  1. Tweak partitioning documentation wording

  2. docs: Rework sections on partition pruning/exclusion

  3. Add GUC enable_partition_pruning