Re: Should we add GUCs to allow partition pruning to be disabled?
От | Amit Langote |
---|---|
Тема | Re: Should we add GUCs to allow partition pruning to be disabled? |
Дата | |
Msg-id | e2184173-fd31-6c89-e2c9-c2db970bc1b2@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Should we add GUCs to allow partition pruning to be disabled? (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | 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 по дате отправления: