Re: rows estimate in explain analyze for the BRIN index - Mailing list pgsql-hackers

From Oleksii Kliukin
Subject Re: rows estimate in explain analyze for the BRIN index
Date
Msg-id C6DE8906-2887-4933-9A87-0D08E1558F17@hintbits.com
Whole thread Raw
In response to Re: rows estimate in explain analyze for the BRIN index  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: rows estimate in explain analyze for the BRIN index  (Emre Hasegeli <emre@hasegeli.com>)
List pgsql-hackers
> On 30 Dec 2015, at 18:38, Emre Hasegeli <emre@hasegeli.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’tthink “0” is a non-confusing representation of “unknown” for most people, and from the practical standpoint, a
“besteffort” estimate is better than 0 (i.e. I will be able to estimate how efficient BRIN index is for my tables in
termsof 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
bitmapscan and point people asking similar questions there. 





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?
Next
From: Shay Rojansky
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?