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 CAKJS1f8tV0w5WjHPVoLA_mNQ9a_cyKghCkMjVBOD=tUJY5zbQg@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?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: Should we add GUCs to allow partition pruning to be disabled?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 20 April 2018 at 14:07, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> To clarify: if we're going to add a new parameter *for partitioned tables*
> to configure whether or not pruning occurs, even if UPDATE and DELETE now
> rely on constraint exclusion for pruning, we should ignore the setting of
> constraint_exclusion the configuration parameter.  For UPDATE and DELETE,
> if enable_partition_pruning is on, we proceed to prune using constraint
> exclusion (because that's the only method available now), irrespective of
> the setting of constraint_exclusion.
>
> So to users, enable_partition_pruning should be the only way to configure
> whether or not pruning occurs.

I hope the attached implements what is being discussed here.

Please test it to ensure it behaves as you'd expect.

I was a little unsure if the new GUCs declaration should live in
costsize.c or not since it really has no effect on plan costs, but in
the end, I stuck it there anyway so that it can be with its friends.

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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [sqlsmith] Unpinning error in parallel worker
Next
From: Ashutosh Bapat
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?