Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> On a fresh instance from HEAD with its default configuration, it shows:
> Index Scan using foo_s_idx on foo (cost=0.29..8.39 rows=33333 width=13)
> Index Cond: (s(crit, ackid) = true)
> It seems statistics shown in "pg_stats" view for function "s()" are good. The
> query itself even have the same costs than the query using the syntax tips you
> provide before.
> However, the estimated row number seems wrong in regard with the costs shown
> and statistics.
Yeah. The problem is that clause_selectivity_ext fails to consider
use of statistics if the clause looks like "bool_valued_function(...)".
If it looks like "bool_valued_function(...) = true", that goes down
a different code path that does the right thing.
Additional factors:
* If you just write "WHERE bool_valued_function(...) = true", that
gets stripped down to "WHERE bool_valued_function(...)" in the name
of making equivalent expressions look equivalent. (IS TRUE doesn't
get stripped, which is why you have to use that wording to avoid
that.)
* Index condition building puts back the "= true" in order to
construct something that satisfies the index AM API. And then it
uses that form to get a selectivity estimate for costing purposes
--- so the right number goes into the indexscan cost estimate.
* But the rowcount estimate is made on the form without "= true".
That's the number shown in EXPLAIN and used when considering
joins.
regards, tom lane
