Re: BUG #18643: EXPLAIN estimated rows mismatch - Mailing list pgsql-bugs

From Andrei Lepikhov
Subject Re: BUG #18643: EXPLAIN estimated rows mismatch
Date
Msg-id 27ac7e14-05bb-40c6-85ad-ca6a0b61f512@gmail.com
Whole thread Raw
In response to Re: BUG #18643: EXPLAIN estimated rows mismatch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18643: EXPLAIN estimated rows mismatch
List pgsql-bugs
On 1/10/2024 18:43, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> Given predicate A and B, it is expected that size (SELECT X where A)  <=
>> size (SELECT X WHERE A or B)
>> However, `EXPLAIN SELECT t2.c0 FROM t2 WHERE t2.c0 IN (t2.c0)` returns
>> rows=2537
> 
> I don't see any particular bug here.  If you look closely at the
> EXPLAIN output, you'll see that "t2.c0 IN (t2.c0)" is transformed
> to "c0 IS NOT NULL" --- but only if it's at top level.  So we're
> estimating selectivities for two quite different conditions in
> this example.
> 
> The NOT NULL bit happens because a top-level equality clause
> is transformed into an "EquivalenceClass", and then when we
> notice the class has only one member, we prefer to spit out
> "x IS NOT NULL" rather than "x = x".  That has the same effect
> (at top level of WHERE, anyway) and tends to be estimated
> more accurately.
I think their question was about why 'x IN (x)' transforms differently 
at the top and inside the OR clause. It is pretty typical question.

-- 
regards, Andrei Lepikhov




pgsql-bugs by date:

Previous
From: Craig Milhiser
Date:
Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker
Next
From: Andrei Lepikhov
Date:
Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker