Обсуждение: BUG #3225: BitmapOr plan node does not show currect row count
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.
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? > 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 > >