To: Andreas Kretschmer <akretschmer@spamfence.net>
cc: pgsql-performance@postgresql.org
Subject: Re: bitmap-index-scan slower than normal index scan 
In-reply-to: <20070711183638.GA30872@KanotixBox> 
References: <20070711183638.GA30872@KanotixBox>
Comments: In-reply-to Andreas Kretschmer <akretschmer@spamfence.net>
	message dated "Wed, 11 Jul 2007 20:36:38 +0200"
Date: Wed, 11 Jul 2007 16:04:33 -0400
Message-ID: <1331.1184184273@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Andreas Kretschmer <akretschmer@spamfence.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