"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