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.) > The number of retrieved and thrown away rows are already available on > the upper part of the plan. Bitmap Index Scan should provide the rows > that matched the index. It doesn't have that information. > Another alternative would be just returning > the number of matching pages (by not multiplying with 10). It might > be better understood. No, it would not, at least not unless we found a way to explicitly mark the output as being blocks not rows (which would doubtless break a lot of existing client-side code). Zero is fairly clearly an impossible value, whereas anything that's not zero is going to be taken at face value by many users. On balance I think likely the best thing to do is return zero, and document that behavior. 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