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. Thanks, Amit
