Re: rows estimate in explain analyze for the BRIN index

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.

In response to

Responses

Browse pgsql-hackers by date

  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?