Re: Problem with default partition pruning

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