Re: Should we add GUCs to allow partition pruning to be disabled? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Should we add GUCs to allow partition pruning to be disabled?
Date
Msg-id CAKFQuwaN_wQdGmnBiBgth50npRwGZ06czeEH2wEwT+3BB8FG0g@mail.gmail.com
Whole thread Raw
In response to Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Wed, May 2, 2018 at 4:06 PM, David Rowley <david.rowley@2ndquadrant.com> wrote:
On 1 May 2018 at 21:44, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> About the patch in general, it seems like the newly added documentation
> talks about "Partition Pruning" as something that *replaces* constraint
> exclusion.  But, I think "Partition Pruning" is not the thing that
> replaces constraint exclusion.

Just thinking about this a bit more. I've become a bit concerned that
we've completely misnamed this feature. It's true that at the moment
we build RelOptInfos for all partitions then eliminate what we can,
but the new algorithm that we've been calling "partition pruning" is
really not pruning anything at all, it's selecting the smallest set of
matching partitions. It's only the current usage of the algorithm
that's using it that way, and I kinda hope to change that for PG12.

Isn't the whole thing better to be named "partition selection"?

​The user-exposed Name/GUC need (and in some ways should) ​not reflect the implementation.  Partitioning creates a tree and during planning and execution we prune those branches/paths from the tree that are not going to yield fruit.  Its not like you can outright ignore their existence so at some point you choose to ignore them which is a form of pruning.

Writing that I can support partition_pruning on technical grounds but to what extent are we alienating the international community that we serve?

Maybe "Partition Filtering" (I'm disliking selection, I'm thinking we must always select partitions)

Then again a Google search suggests we will be keeping good company by sticking with "Partition Pruning" - any language dynamic is probably overcome through extent of use.

On the whole I'd stick with what we've got.

David J.

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql
Next
From: David Rowley
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?