Thread

  1. EXPLAIN ANALYZE for bitmapAnd and bitmapOr scans always reports rows = 0

    Joseph Shraibman <jks@selectacast.net> — 2007-07-31T22:26:46Z

     From this snipped you can see that the Bitmap Heap scan returns 123 
    rows, but the BitmapAnd under it returns 0.  I would find it useful to 
    determine how many rows were thrown out by the recheck.
    
                          ->  Bitmap Heap Scan on d  (cost=4959.18..16848.23 
    rows=754 width=10) (actual time=344.126..1534.198 rows=123 loops=1)
                                Recheck Cond: ((s = $0) AND (sdate >= 
    '2007-06-30'::date) AND (sdate <= '2007-07-30'::date))
                                Filter: (snipped filter conditions here)
                                ->  BitmapAnd  (cost=4959.18..4959.18 
    rows=3218 width=0) (actual time=337.002..337.002 rows=0 loops=1)
                                      ->  Bitmap Index Scan on d_idx1 
    (cost=0.00..1035.58 rows=54796 width=0) (actual time=96.478..96.478 
    rows=30338 loops=1)
                                            Index Cond: (s = $0)
                                      ->  Bitmap Index Scan on d_idx2 
    (cost=0.00..3922.98 rows=183437 width=0) (actual time=235.680..235.680 
    rows=181322 loops=1)
                                            Index Cond: ((sdate >= 
    '2007-06-30'::date) AND (sdate <= '2007-07-30'::date))
    
    This was on:
    PostgreSQL 8.2.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 
    3.4.6 20060404 (Red Hat 3.4.6-3)
    
    
  2. Re: EXPLAIN ANALYZE for bitmapAnd and bitmapOr scans always reports rows = 0

    Heikki Linnakangas <heikki@enterprisedb.com> — 2007-08-01T19:02:45Z

    Joseph S wrote:
    > From this snipped you can see that the Bitmap Heap scan returns 123
    > rows, but the BitmapAnd under it returns 0.  I would find it useful to
    > determine how many rows were thrown out by the recheck.
    
    Yeah, it would be nice. Unfortunately there's some problems with that,
    see previous discussion on that:
    http://archives.postgresql.org/pgsql-bugs/2007-04/msg00029.php
    
    -- 
      Heikki Linnakangas
      EnterpriseDB   http://www.enterprisedb.com