Tom Lane wrote:
> Emre Hasegeli <e...@hasegeli.com> writes:
> >> I don’t see how to solve this problem without changing explain analyze
> >> output to accommodate for “unknown” value. I don’t think “0” is a
> >> non-confusing representation of “unknown” for most people, and from the
> >> practical standpoint, a “best effort” estimate is better than 0 (i.e. I
> >> will be able to estimate how efficient BRIN index is for my tables in
> >> terms of the number of tuples retrieved/thrown away)
>
> We do already have a nearby precedent for returning zero when we don't
> have an accurate answer: that's what BitmapAnd and BitmapOr plan nodes
> do. (This is documented btw, at the bottom of section 14.1.)
Hmm, but amgetbitmap is documented thusly:
The number of tuples fetched is returned (this might be just an
approximate count, for instance some AMs do not detect
duplicates).
http://www.postgresql.org/docs/9.5/static/index-functions.html
so I'm not sure we're actually violating an expectation that the number
of rows is exact. I mean, if we zero out this one, shouldn't we set it
to zero for these other documented cases too?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
