здраствуйте

вот что мне Postgres выдал:

\d pkeyword
Table "public.pkeyword"
Column | Type | Modifiers
-----------------+---------+-----------------------------------------------------------------------
pkey | bigint | not null default nextval(('pkeyword_pkey_seq'::text)::regclass) keywordtype | integer |
keywordid | integer |
id | integer |

Indexes:
"pkeyword_pkey" PRIMARY KEY, btree (pkey)
"pkeyword_real_pkey" UNIQUE, btree (keywordtype, keywordid, id)
"pkeyword_by_keyword" btree (keywordtype, keywordid)
"pkeyword_by_keywordtype" btree (keywordtype)
"pkeyword_by_id" btree (id)


set enable_bitmapscan to on


QUERY PLAN
----------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on pkeyword (cost=3890.97..3970.87 rows=20 width=4)
Recheck Cond: ((id = 801865) AND (keywordtype = 72))
-> BitmapAnd (cost=3890.97..3890.97 rows=20 width=0)
-> Bitmap Index Scan on pkeyword_by_id (cost=0.00..13.01 rows=2002 width=0)
Index Cond: (id = 801865)
-> Bitmap Index Scan on pkeyword_by_keywordtype (cost=0.00..3877.71 rows=681345 width=0)
Index Cond: (keywordtype = 72)

set enable_bitmapscan to off

QUERY PLAN
---------------------------------------------------------------------------------------------------
Index Scan using proteinkeyword_real_pkey on proteinkeyword (cost=0.00..6776.88 rows=20 width=4) Index Cond: ((keywordtype = 72) AND (protid = 801865))

вот так вот..
как объяснить?

Funny_FalconЧто именно? То что PostgreSQL 8.1 умеет строить runtime bitmap карты используя имеющиеся индексы?
Конечено не всегда это дает ускорение, но в 80% случаев - точно дает.

да после upgrade Postgres стал работать на порядок медленнее на запросе
поэтоиу интересно знать почему он выбрал именно этот план выполнения?