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

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?
Date: 2018-05-01 23:18:11
Message-ID: CAKJS1f-S1b44ejxr1gPbY9opUXx_yhLJB3jqf5uhx5jJ39-qnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Amit,

Thanks for looking at the patch.

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.

Not sure where you see the mention partition pruning replacing
constraint exclusion.

> We used to do partition pruning even
> before and used constraint exclusion as the algorithm.

That depends on if you think of partition pruning as the new feature
or the act of removing unneeded partitions. We seem to have settled on
partition pruning being the new feature given that we named the GUC
this way. So I don't quite understand what you mean here.

> What's new is the
> algorithm that we now use to perform partition pruning for declaratively
> partitioned tables. Also, the characteristics of the new algorithm are
> such that it can now be used in more situations, thus making it more
> useful than the earlier method of partition pruning, so that new features
> like runtime pruning could be realized. I like that the patch adds
> various details about the new pruning features, but think that the wording
> and the flow could be improved a bit.
>
> What do you think?

I re-read the patch and it still looks fine to me. I'm sure it could
be made better, but I just don't currently see how. I think it would
be better if you commented on the specifics of what you think could be
improved rather than a general comment that it could be improved.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-05-01 23:35:18 pgsql: Clean up warnings from -Wimplicit-fallthrough.
Previous Message Peter Geoghegan 2018-05-01 22:37:33 Re: [HACKERS] Clock with Adaptive Replacement