At Mon, 08 Apr 2019 20:42:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20190408.204251.143128146.horiguchi.kyot...@lab.ntt.co.jp> > At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" > <hosoya.yuz...@lab.ntt.co.jp> wrote in > <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > > 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)". Mmm. Something is wrong. I should have been sleeping at the time. In my opinion, what we should there is: - Try partition pruning first. - If the partition was not pruned, and constraint is set, check for constant false. - if constraint_exclusion is turned on and constraint is set, examine the constraint. Sorry for the stupidity. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
