Re: Should we add GUCs to allow partition pruning to be disabled?

On Wed, May 2, 2018 at 4:06 PM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:

> On 1 May 2018 at 21:44, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.