Re: bitmap-index-scan slower than normal index scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: bitmap-index-scan slower than normal index scan
Date
Msg-id 1331.1184184273@sss.pgh.pa.us
Whole thread Raw
In response to bitmap-index-scan slower than normal index scan  (Andreas Kretschmer <akretschmer@spamfence.net>)
Responses Re: bitmap-index-scan slower than normal index scan
List pgsql-performance
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.459rows=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

pgsql-performance by date:

Previous
From: "Alex Deucher"
Date:
Subject: Re: bitmap-index-scan slower than normal index scan
Next
From: Andreas Kretschmer
Date:
Subject: Re: bitmap-index-scan slower than normal index scan