At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in
<494124a7-d305-1bc9-ef64-d5c790e13e86@lab.ntt.co.jp>
> On 2019/04/09 17:37, Kyotaro HORIGUCHI wrote:
> > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp> wrote
> >>> So still it is wrong that the new code is added at the beginning of the loop on clauses in
> >>> gen_partprune_steps_internal.
> >>>
> >>>> If partqual results true and the clause
> >>>> is long, the partqual is evaluated uselessly at every recursion.
> >>>>
> >>>> Maybe we should do that when we find that the current clause doesn't
> >>>> match part attributes. Specifically just after the for loop "for (i =
> >>>> 0 ; i < part_scheme->partnattrs; i++)".
> >>>
> >> I think we should check whether WHERE clause contradicts partition
> >> constraint even when the clause matches part attributes. So I moved
> >
> > Why? If clauses contains a clause on a partition key, the clause
> > is involved in determination of whether a partition survives or
> > not in ordinary way. Could you show how or on what configuration
> > (tables and query) it happens that such a matching clause needs
> > to be checked against partqual?
> >
> > The "if (partconstr)" block uselessly runs for every clause in
> > the clause tree other than BoolExpr. If we want do that, isn't
> > just doing predicate_refuted_by(partconstr, clauses, false)
> > sufficient before looping over clauses?
>
> Yeah, I think we should move the "if (partconstr)" block to the "if
> (is_orclause(clause))" block as I originally proposed in:
>
> https://www.postgresql.org/message-id/9bb31dfe-b0d0-53f3-3ea6-e64b811424cf%40lab.ntt.co.jp
>
> It's kind of a hack to get over the limitation that
> get_matching_partitions() can't prune default partitions for certain OR
> clauses and I think we shouldn't let that hack grow into what seems like
> almost duplicating relation_excluded_by_constraints() but without the
> constraint_exclusion GUC guard.
That leaves an issue of contradicting clauses that is not an arm
of OR-expr. Isn't that what Hosoya-san is trying to fix?
--
Kyotaro Horiguchi
NTT Open Source Software Center
