Tom Lane wrote:
> Emre Hasegeli <emre@hasegeli.com> writes:
> >> I don’t see how to solve this problem without changing explain analyze output to accommodate for “unknown” value.
Idon’t think “0” is a non-confusing representation of “unknown” for most people, and from the practical standpoint, a
“besteffort” estimate is better than 0 (i.e. I will be able to estimate how efficient BRIN index is for my tables in
termsof 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 anapproximate count, for instance some AMs do not
detectduplicates).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
