Re: Problem with default partition pruning

At Mon, 08 Apr 2019 20:42:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190408(dot)204251(dot)143128146(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp> wrote in <00c101d4ede0$babd4390$3037cab0$(at)lab(dot)ntt(dot)co(dot)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