Jens-Wolfhard Schicke wrote:
> I an explain analyze I saw recently, a BitmapOr node of 5 Bitmap Index Scan
> looked like this:
>
> BitmapOr (cost=43.57..43.57 rows=1833 width=0) (actual time=0.146..0.146
> rows=0 loops=1)
>
> Yet, the last subnode was:
>
> Bitmap Index Scan on location_gs (cost=0.00..8.14 rows=251 width=0) (actual
> time=0.094..0.094 rows=375 loops=1)
>
> The real rowcount of the BitmapOr is wrong.
Thanks for the report.
We don't show the real row count for BitmapAnd and BitmapOr nodes,
because it's not clear how to calculate it. We could scan through the
resulting bitmap and count all the set bits, but as soon as it grows big
enough and becomes lossy, which means that we only store one bit for
each page that contains matching rows and recheck the conditions for
every row on the page later, we no longer have enough information to
count the actual row count.
Agreed, always reporting a zero is a bit misleading. We could refrain
from printing the "rows=0" for those nodes altogether, or report the
number of lossy and non-lossy bits in the bitmap instead, but that would
add some complexity to the backend, as well as requiring support from
clients that parse the output.
The actual row count of the corresponding Bitmap Heap Scan is correct,
you can look at that instead.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com