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

David Rowley 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"?

I think that approach makes it more difficult to explain, not less so.

There are two logically opposite ways to explain this feature: a) by
default, all partitions must be scanned, and we examine the query to
determine which ones can be pruned. b) by default, no partitions are
scanned, and we examine the query to determine which ones must be
scanned.

The whole "enable_partition_pruning" thing is based on the idea that we
do a). You propose that we do b) instead. The only difference is what
happens if the feature is disabled -- the "by default" clause gets
inverted. So it would have to be b) if the feature is enabled, by
default no partitions are scanned, and we examine the query to determine
which ones must be scanned; if the feature is disabled, all partitions
must be scanned.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services