From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(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-04-18 01:03:06 |
Message-ID: | CAKFQuwbTz7M4D0M1C-XpzSO-8izjAzq80H=87Z_yXSom7yWDqA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 17, 2018 at 5:42 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> On Wed, Apr 18, 2018 at 12:07:18PM +1200, David Rowley wrote:
> > In PG10 the planner's partition pruning could be disabled by changing
> > the constraint_exclusion GUC to off. This is still the case for PG11,
> > but only for UPDATE and DELETE queries. There is currently no way to
> > disable partition pruning for SELECT.
> >
> > Should we allow this?
>
> > 3. No new GUCs / Do nothing.
>
> Maybe this is divergent from the details of the implementation; but, from a
> user's perspective: why not continue to use constraint_exclusion?
>
> I would suggest to add zero new GUCs:
>
> 0. constraint_exclusion={off,partition,on,PLANNER*,EXECUTOR*}
>
My initial reaction is that we need to fix the bug introduced in v10 -
leaving constraint_exclusion working as it has historically and not affect
the new-as-of-10 ability to prune (maybe better termed as skip...)
partitions known during execution to contain no qualified tuples.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-18 01:12:19 | Re: Should we add GUCs to allow partition pruning to be disabled? |
Previous Message | Michael Paquier | 2018-04-18 01:00:59 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |