"Sergey E. Koposov" <[EMAIL PROTECTED]> 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=0 loops=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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
