Skip site navigation (1) Skip section navigation (2)

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

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Jens-Wolfhard Schicke <j(dot)schicke(at)asco(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3225: BitmapOr plan node does not show currect row count
Date: 2007-04-13 14:45:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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

In response to

pgsql-bugs by date

Next:From: sean songDate: 2007-04-13 14:49:19
Subject: BUG #3227: ODBC driver with subqueries destroy transaction context
Previous:From: sean songDate: 2007-04-13 14:30:49
Subject: BUG #3226: ODBC driver 8.02.02 parses subqueries incorrectly

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group