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

"Sergey E. Koposov" <math@sai.msu.ru> 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