At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote in <494124a7-d305-1bc9-ef64-d5c790e13...@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.yuz...@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
