Re: performance of bitmap scans in nested loop joins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: performance of bitmap scans in nested loop joins
Date
Msg-id 7409.1114797675@sss.pgh.pa.us
Whole thread Raw
In response to performance of bitmap scans in nested loop joins  ("Sergey E. Koposov")
Responses Re: performance of bitmap scans in nested loop joins  ("Sergey E. Koposov")
List pgsql-hackers
"Sergey E. Koposov" <> writes:
> I'd like to report about suprising (for me) results of performance testing of
> bitmap  indexes in nested loop join plans. 

I'm surprised too.  There's something weird in the indexscans
themselves:

>    ->  Index Scan using ipix_idx on q3c  (cost=0.01..9686.37 rows=333335 width=48) (actual time=0.006..0.006 rows=0
loops=3000000)
>          Index Cond: ((q3c.ipix >= ("outer".ipix - 1000)) AND (q3c.ipix <= ("outer".ipix - 993)))

>                ->  Bitmap Index Scan on ipix_idx  (cost=0.00..2916.02 rows=333335 width=0) (actual time=0.011..0.011
rows=0loops=3000000)
 
>                      Index Cond: ((q3c.ipix >= ("outer".ipix - 1000)) AND (q3c.ipix <= ("outer".ipix - 993)))

The latter is (or should be) doing slightly *less* work, so why is it
taking almost twice as much time?  Can you get gprof profiles of the
two cases?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Returning a RECORD, not SETOF RECORD
Next
From: Alvaro Herrera
Date:
Subject: Re: [proposal] protocol extension to support loadable stream filters