Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Pierre" == Pierre Ducroquet <p.psql@pinaraf.info> writes:
> Pierre> The attached patch handles both situations. When flattening and
> Pierre> simplifying the AND clauses, a list of the NullChecks is built,
> Pierre> and subsequent NullChecks are compared to the list. If opposite
> Pierre> NullChecks on the same variable are found, the whole AND is
> Pierre> optimized away.
> That's all very well but it's very specific to a single use-case. The
> existing code, when you enable it, can detect a whole range of possible
> refutations (e.g. foo > 1 AND foo < 1).
Yeah. Just for the record, if we were interested in taking a patch
for this purpose, simplify_and_arguments is a poor choice of where
to do it anyway. That would only find contradictions between clauses
that were in the same expression at eval_const_expressions time, which
is pretty early and will miss a lot of logically-equivalent situations
(e.g. if one clause is in a JOIN...ON and the other is in WHERE).
The constraint exclusion code looks for contradictions between clauses
that have been pushed down to the same relation during jointree
deconstruction, ie they have the same set of referenced relations.
That would be a much better place for this type of logic.
regards, tom lane
