Hi. On 2018/04/20 11:18, David Rowley wrote: > On 20 April 2018 at 14:07, Amit Langote <langote_amit...@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. >> >> 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
