| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Oleksii Kliukin <alexk(at)hintbits(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: | 2016-01-03 12:17:28 |
| Message-ID: | CAE2gYzyp_+KPSgOVsV338jgorO3b9xSM9StiyJ=Q+-D7Ph6KvA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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].
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2016-01-03 13:26:44 | Re: Support for N synchronous standby servers - take 2 |
| Previous Message | Erik Rijkers | 2016-01-03 10:25:51 | Re: commitfest html - wrong closing tag |