The following bug has been logged online:

Bug reference: 3225
Logged by: Jens-Wolfhard Schicke
Email address: j.schicke@asco.de
PostgreSQL version: 8.2
Operating system: Linux
Description: BitmapOr plan node does not show currect row count
Details:

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.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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?

> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match