From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: ming wei tan <mingwei.tc@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18643: EXPLAIN estimated rows mismatch
Date: Thu, 03 Oct 2024 00:40:02 -0400
Message-ID: <240412.1727930402@sss.pgh.pa.us> (raw)
In-Reply-To: <bc9562f9-5e6b-498d-9243-697a56961292@gmail.com>
References: <18643-8d455145acd8243e@postgresql.org>
<1860123.1727801026@sss.pgh.pa.us>
<27ac7e14-05bb-40c6-85ad-ca6a0b61f512@gmail.com>
<CAALvCkZz+7hpdsg-cSV93QK4jwVw1z7E5CS3+w-mmCp__Tpu0g@mail.gmail.com>
<CAApHDvqqQrVeZ0A5eyPDwOpFRA=xGHgKZp=iY3gKU4gZ4UyVwg@mail.gmail.com>
<bc9562f9-5e6b-498d-9243-697a56961292@gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, lepihov@gmail.com, dgrowleyml@gmail.com, mingwei.tc@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18643: EXPLAIN estimated rows mismatch
In-Reply-To: <240412.1727930402@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox