Re: BUG #18643: EXPLAIN estimated rows mismatch
От | Andrei Lepikhov |
---|---|
Тема | Re: BUG #18643: EXPLAIN estimated rows mismatch |
Дата | |
Msg-id | 27ac7e14-05bb-40c6-85ad-ca6a0b61f512@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18643: EXPLAIN estimated rows mismatch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18643: EXPLAIN estimated rows mismatch
|
Список | 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 по дате отправления: