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

From Emre Hasegeli
Subject Re: rows estimate in explain analyze for the BRIN index
Date
Msg-id CAE2gYzyp_+KPSgOVsV338jgorO3b9xSM9StiyJ=Q+-D7Ph6KvA@mail.gmail.com
Whole thread Raw
In response to Re: rows estimate in explain analyze for the BRIN index  (Oleksii Kliukin <alexk@hintbits.com>)
List pgsql-hackers
> But is it? Is it impossible for the BRIN bitmap index scan to return 0 rows
> (say, if the value being matched is outside the min/max boundary for every
> block range?) Granted, if we document that it always returns 0 and should be
> ignored, then confusing the actual 0 with the 0 as a representation of
> “unknown” would be less a problem.

How about -1 ?  It is an impossible value for sure.  Maybe we should
change BitmapAnd and BitmapOr nodes, too.  It is better to make it
obvious that it is not the correct value.  I don't think many people
would notice the note on the documentation.

On the other hand, returning -1 broke parser of explain.depesz.com [1].

[1] http://explain.depesz.com/s/tAkd



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: commitfest html - wrong closing tag
Next
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2