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

From Amit Langote
Subject Re: Should we add GUCs to allow partition pruning to be disabled?
Date
Msg-id e2184173-fd31-6c89-e2c9-c2db970bc1b2@lab.ntt.co.jp
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>)
List pgsql-hackers
On 2018/04/20 17:51, Amit Langote wrote:
> On 2018/04/20 14:47, David Rowley wrote:
>> 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.
> 
> The patch looks good except one thing,
OK, I forgot to comment on a couple of minor issues.

+     <varlistentry id="guc-enable-partition-pruning"
xreflabel="enable_partition_pruning">
+      <term><varname>enable_partition_pruning</varname>
(<type>boolean</type>)
+       <indexterm>
+        <primary><varname>enable_partition_pruning</varname>
configuration parameter</primary>
+       </indexterm>
+      </term>
+      <listitem>
+       <para>
+        Enables or disables the query planner's ability to eliminate a
+        partitioned table's subpartitions from query plans.

Why subpartitions?  Maybe, just "partitions" is fine.

+  This also
+        controls the planner's ability to generate query plans which
allow the
+        query executor to remove or ignoring partitions during query

Here: ignoring -> ignore

Also, maybe add the GUC to postgresql.conf.sample.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Built-in connection pooling
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooling