mirror of
https://github.com/postgres/postgres.git
synced 2025-11-21 00:42:43 +03:00
Improve predtest.c's internal docs, and enhance its functionality a bit.
Commitb08df9cableft things rather poorly documented as far as the exact semantics of "clause_is_check" mode went. Also, that mode did not really work correctly for predicate_refuted_by; although given the lack of specification as to what it should do, as well as the lack of any actual use-case, that's perhaps not surprising. Rename "clause_is_check" to "weak" proof mode, and provide specifications for what it should do. I defined weak refutation as meaning "truth of A implies non-truth of B", which makes it possible to use the mode in the part of relation_excluded_by_constraints that checks for mutually contradictory WHERE clauses. Fix up several places that did things wrong for that definition. (As far as I can see, these errors would only lead to failure-to-prove, not incorrect claims of proof, making them not serious bugs even aside from the fact that v10 contains no use of this mode. So there seems no need for back-patching.) In addition, teach predicate_refuted_by_recurse that it can use predicate_implied_by_recurse after all when processing a strong NOT-clause, so long as it asks for the correct proof strength. This is an optimization that could have been included in commitb08df9cab, but wasn't. Also, simplify and generalize the logic that checks for whether nullness of the argument of IS [NOT] NULL would force overall nullness of the predicate or clause. (This results in a change in the partition_prune test's output, as it is now able to prune an all-nulls partition that it did not recognize before.) In passing, in PartConstraintImpliedByRelConstraint, remove bogus conversion of the constraint list to explicit-AND form and then right back again; that accomplished nothing except forcing a useless extra level of recursion inside predicate_implied_by. Discussion: https://postgr.es/m/5983.1520487191@sss.pgh.pa.us
This commit is contained in:
@@ -1421,7 +1421,11 @@ relation_excluded_by_constraints(PlannerInfo *root,
|
||||
safe_restrictions = lappend(safe_restrictions, rinfo->clause);
|
||||
}
|
||||
|
||||
if (predicate_refuted_by(safe_restrictions, safe_restrictions, false))
|
||||
/*
|
||||
* We can use weak refutation here, since we're comparing restriction
|
||||
* clauses with restriction clauses.
|
||||
*/
|
||||
if (predicate_refuted_by(safe_restrictions, safe_restrictions, true))
|
||||
return true;
|
||||
|
||||
/*
|
||||
@@ -1469,6 +1473,9 @@ relation_excluded_by_constraints(PlannerInfo *root,
|
||||
* an obvious optimization. Some of the clauses might be OR clauses that
|
||||
* have volatile and nonvolatile subclauses, and it's OK to make
|
||||
* deductions with the nonvolatile parts.
|
||||
*
|
||||
* We need strong refutation because we have to prove that the constraints
|
||||
* would yield false, not just NULL.
|
||||
*/
|
||||
if (predicate_refuted_by(safe_constraints, rel->baserestrictinfo, false))
|
||||
return true;
|
||||
|
||||
Reference in New Issue
Block a user