At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" <[email protected]> wrote in <[email protected]> > > BTW, now I'm a bit puzzled between whether this case should be fixed by > > hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and > > expect users to set > > constraint_exclusion = on for this to behave as expected. The original > > intention of setting > > partition_qual in set_relation_partition_info() was for partprune.c to use > > it to remove useless > > arguments of OR clauses which otherwise would cause the failure to > > correctly prune the default partitions > > of sub-partitioned tables. As shown by the examples in this thread, the > > original effort was > > insufficient, which this patch aims to improve. But, it also expands the > > scope of partprune.c's usage > > of partition_qual, which is to effectively perform full-blown constraint > > exclusion without being > > controllable by constraint_exclusion GUC, which may be seen as being good > > or bad. The fact that it > > helps in getting partition pruning working correctly in more obscure cases > > like those discussed in > > this thread means it's good maybe. > > > Umm, even though this modification might be overhead, I think this problem > should be solved > without setting constraint_exclusion GUC. But I'm not sure.
Partition pruning and constraint exclusion are orthogonal functions. Note that the default value of the variable is CONSTRAINT_EXCLUSION_PARTITION and the behavior is not a perfect bug. So I think we can reasonably ignore constraints when constraint_exclusion is intentionally turned off. As the result I propose to move the "if(partconstr)" block in the latest patches after the constant-false block, changing the condition as "if (partconstr && constraint_exclusion != CONSTRAINT_EXCLUSION_OFF)". This make partprune reacts to constraint_exclusion the consistent way with the old-fashioned partitioning. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
