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. > 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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services