From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
---|---|
To: | emre(at)hasegeli(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 18:01:26 |
Message-ID: | C6DE8906-2887-4933-9A87-0D08E1558F17@hintbits.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 30 Dec 2015, at 18:38, Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
>
>> which is much closer to the actual number of rows removed by the index
>> recheck + the one left.
>
> Is it better to be closer? We are saying those are the "actual"
> values not the estimates. If we cannot provide the actual rows, I
> think it is better to provide nothing. Something closer to the
> reality would create more confusion. Maybe, we just just return the
> number of blocks, and put somewhere a note about it. The actual row
> count is already available on the upper part of the plan.
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 might still reflect in the documentation that the BRIN index cannot produce the exact number of rows during the bitmap scan and point people asking similar questions there.
From | Date | Subject | |
---|---|---|---|
Next Message | Shay Rojansky | 2015-12-30 18:02:29 | Re: Some 9.5beta2 backend processes not terminating properly? |
Previous Message | Andres Freund | 2015-12-30 17:58:45 | Re: Some 9.5beta2 backend processes not terminating properly? |