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