Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane wrote: >> 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? Well, the code comments may say that, but the user-facing docs don't ... More generally, people are accustomed to the idea that the planner's estimated rowcounts are just estimates, but they're not accustomed to the idea that the runtime "actual" rowcounts might be just estimates. That seems like it's moving EXPLAIN ANALYZE's contract quite a bit, even if there are some documents for internal APIs that say something else. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
