BUG #3225: BitmapOr plan node does not show currect row count

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

"Jens-Wolfhard Schicke" <j.schicke@asco.de> writes:

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)

BitmapOr and BitmapAnd don't attempt to count their result rows --- doing
so would involve an extra scan over the bitmap, and what would you do
for lossy pages?

regards, tom lane

Tom Lane wrote:

"Jens-Wolfhard Schicke" <j.schicke@asco.de> writes:

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)

Can we do better than just saying 0? something indicating not
calculated, or the fact we can't calculate it?