From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | emre(at)hasegeli(dot)com |
Cc: | Oleksii Kliukin <alexk(at)hintbits(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: rows estimate in explain analyze for the BRIN index |
Date: | 2015-12-30 20:12:16 |
Message-ID: | 23886.1451506336@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
>> I dont see how to solve this problem without changing explain analyze output to accommodate for unknown value. I dont 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-12-30 20:26:05 | Re: On columnar storage (2) |
Previous Message | Emre Hasegeli | 2015-12-30 19:56:24 | Re: rows estimate in explain analyze for the BRIN index |