Re: bitmap-index-scan slower than normal index scan

Andreas Kretschmer <akretschmer(at)spamfence(dot)net> writes:
> Okay, i know, not really a recent version:
> PostgreSQL 8.1.4 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5 (Debian 1:3.3.5-13)

You need a newer one.

> -> BitmapAnd (cost=1217.69..1217.69 rows=39 width=0) (actual time=163.681..163.681 rows=0 loops=1)
> -> Bitmap Index Scan on idx_ab (cost=0.00..5.95 rows=558 width=0) (actual time=0.078..0.078 rows=109 loops=1)
> Index Cond: (ab = 347735)
> -> Bitmap Index Scan on idx_maschine (cost=0.00..1211.49 rows=148997 width=0) (actual time=163.459..163.459 rows=164760 loops=1)
> Index Cond: (maschine = 1200)

This is simply a stupid choice on the part of choose_bitmap_and() ---
it's adding on a second index to try to filter on maschine when that
scan will actually just increase the cost.

I've revisited choose_bitmap_and() a couple times since then; try
8.1.9 and see if it gets this right.

Also, part of the problem here looks to be an overestimate of the number
of rows matching ab = 347735. It might help to increase the statistics
target for that column.

regards, tom lane