Re: rows estimate in explain analyze for the BRIN index

Поиск
Список
Период
Сортировка
От Oleksii Kliukin
Тема Re: rows estimate in explain analyze for the BRIN index
Дата
Msg-id C6DE8906-2887-4933-9A87-0D08E1558F17@hintbits.com
обсуждение исходный текст
Ответ на Re: rows estimate in explain analyze for the BRIN index  (Emre Hasegeli <emre@hasegeli.com>)
Ответы Re: rows estimate in explain analyze for the BRIN index  (Emre Hasegeli <emre@hasegeli.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Some 9.5beta2 backend processes not terminating properly?
Следующее
От: Shay Rojansky
Дата:
Сообщение: Re: Some 9.5beta2 backend processes not terminating properly?