Re: BUG #18643: EXPLAIN estimated rows mismatch
От | Tom Lane |
---|---|
Тема | Re: BUG #18643: EXPLAIN estimated rows mismatch |
Дата | |
Msg-id | 1860123.1727801026@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18643: EXPLAIN estimated rows mismatch (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18643: EXPLAIN estimated rows mismatch
|
Список | pgsql-bugs |
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. In any case, in this toy example that lacks an ANALYZE step, the selectivity estimates are mostly going to be garbage. regards, tom lane
В списке pgsql-bugs по дате отправления: