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

Hi.

On 2018/04/20 11:18, David Rowley wrote:
> On 20 April 2018 at 14:07, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.
>>
>> Does that make sense?
>
> So to summarise my understanding (plus filling in the blanks):
>
> 1. Add single GUC named enable_partition_pruning, default = on.
> 2. Check this setting in set_append_rel_size to only perform
> prune_append_rel_partitions when enable_partition_pruning is true.
> 3. Add code in create_append_plan to only call
> make_partition_pruneinfo when enable_partition_pruning is true.
> 4. Replace test doing (constraint_exclusion ==
> CONSTRAINT_EXCLUSION_PARTITION) with (enable_partition_pruning).
> 5. Get rid of CONSTRAINT_EXCLUSION_PARTITION.
>
> I don't think you mentioned 5. but if I understand you correctly then
> it would leave that option doing nothing. So we should remove it.

About 4 & 5:

Perhaps we should leave constraint_exclusion = partition alone because
there might be users who want to continue using the old inheritance method
to set up partitioning for whatever reason?

>> BTW, should this thread be listed somewhere on the open items page?
>
> Yeah. we need to decide this before PG11 is let loose. I will add it.

OK, thanks.

Regards,
Amit

[1]
https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#DDL-PARTITIONING-IMPLEMENTATION-INHERITANCE