Emre Hasegeli <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
