Re: BUG #18643: EXPLAIN estimated rows mismatch

Andrei Lepikhov <lepihov@gmail.com> writes:
> So, we already pass through the OR clauses. Why not to check semi-equal 
> clauses and remove duplicates even if not all clauses are such 
> duplicates? At least, it continually raises users' questions.

It's difficult to justify spending extra planner cycles to optimize
what are fundamentally stupidly-written queries.  Who writes "X=X"
in the first place?  (Other than ORM authors who need to spend some
time in a re-education camp.)  And it would not be a trivial number
of extra cycles, either.  As pointed out in the commit message
David mentioned, it's basically free to make this improvement
when we're looking at a potential EquivalenceClass clause.
We've already paid the cost of checking that the operator is a btree
equality operator, and we know that the clause is at top level of
WHERE (else we couldn't fuzz over the difference between false and
null results), and besides we have to check whether it's "X=X" because
not doing so causes some semantic problems for the EquivalenceClass
machinery.  In the case of a random clause-underneath-OR, we would
have to make a brand new check whether it's btree equality, and we
would have to somehow track whether we had descended to an expression
level where "false and null are known equivalent" is no longer true.
So I really doubt that a case can be made that that is worth doing.

            regards, tom lane