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

From David Rowley
Subject Re: Should we add GUCs to allow partition pruning to be disabled?
Date
Msg-id CAKJS1f84ZktJex652sBgDyFkbgoeyA7PRH_o3jzZQ7982CP4dA@mail.gmail.com
Whole thread Raw
In response to Re: Should we add GUCs to allow partition pruning to be disabled?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Should we add GUCs to allow partition pruning to be disabled?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Should we add GUCs to allow partition pruning to be disabled?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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"?

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is there a memory leak in commit 8561e48?
Next
From: Thomas Munro
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql