| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Á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 19:56:24 |
| Message-ID: | CAE2gYzyQTZihX9GbZTesWiJT55xPLrbtBwiRey3qhqMBOiSLmQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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)
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. Another alternative would be just returning
the number of matching pages (by not multiplying with 10). It might
be better understood. The users who can understand the EXPLAIN
ANALYZE output shouldn't be expecting BRIN to return rows.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-12-30 20:12:16 | Re: rows estimate in explain analyze for the BRIN index |
| Previous Message | Pavel Stehule | 2015-12-30 19:28:07 | Re: custom function for converting human readable sizes to bytes |