[postgresql] query pakt index niet?

[Verwijderd]

Ik heb een probleem met een query op een postgresql database. Hij gebruikt namelijk m'n index niet. Het gaat om de volgende query:

select * from egproperties where tabel = 'og'

egproperties is een tabel met zo'n 1500 records (verders geen triggers, indexen, een normale simpele tabel dus). Ik heb een btree index gemaakt op de tabel kolom:

CREATE INDEX index_egproperties_tabel ON egproperties USING btree (tabel)

Daarna heb ik een full vacuum analyze gedaan om er zeker van te zijn dat alle indexes "gevult" zijn.

Maar als ik nu het volgende doe:

explain analyze select * from egproperties where tabel = 'og'

word de index die op de kolom tabel zit niet gebruikt:

Seq Scan on egproperties (cost=0.00..49.45 rows=260 width=149) (actual time=0.33..22.43 rows=260 loops=1)
Filter: (tabel = 'og'::character varying)
Total runtime: 23.57 msec

Ik vermoed dat ik iets fout doe, maar ik kan niet vinden wat. Weten jullie waarom hij m'n index niet gebruikt?

[whoami]

Misschien is die index niet uniek genoeg, en beslist de optimizer dan maar dat een full table access interessanter is dan gebruik te maken van die index.
Ik ken Postgresql niet, maar misschien heb je daar ook wel zoiets als 'index hints' oid zoals in Sql Server. Daarmee kan je in je query specifieren dat een bepaalde index moet gebruikt worden. (Dit is echter slechts in bepaalde gevallen aan te raden; de optimizer doet het nl. in vrijwel alle gevallen goed. Zelf bepalen of en welke index er moet gebruikt worden is niet altijd even handig).

[ACM]

Aangezien er 260 uit 1500 records uitrollen lijkt het me niet heel onwaarschijnlijk wat whoami vermeld. Als postgresql volgens de statistische informatie schat dat het gros van de table-pages (waar per stuk meerdere records in staan) toch benaderd zal moeten worden, zal postgresql besluiten dat het dan waarschijnlijk sneller is om dan maar een sequential scan op de tabel uit te voeren (want het gros van de pages moet toch ingeladen worden en de scan van een page in het geheugen is vrij snel te doen) en de index links te laten liggen.

[ Voor 13% gewijzigd door ACM op 16-06-2004 13:30 ]

[Verwijderd]

Klopt helemaal, die optimizer is slimmer dan mij