Re: bitmap-index-scan slower than normal index scan
От | Tom Lane |
---|---|
Тема | Re: bitmap-index-scan slower than normal index scan |
Дата | |
Msg-id | 1331.1184184273@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | bitmap-index-scan slower than normal index scan (Andreas Kretschmer <akretschmer@spamfence.net>) |
Ответы |
Re: bitmap-index-scan slower than normal index scan
|
Список | 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 по дате отправления: