Dotaz na optimalizaci - indexy
Jan Serak
sherry na pikebo.cz
Pátek Červen 20 14:49:59 CEST 2003
Ing. Pavel Janousek wrote:
[...]
> Co mne vsak dostalo, tak tento dotaz:
>
> select id, ... from TableA where id not in (select id from TableB) and
> (now() - cas) < 3000000 order by cas desc;
>
> Takze jsem si zacal hrat s indexy,
PostgreSQL neznam, takze budu spis teoretizovat.
Nejprve se podivame na tabulku A. Ten select vyzaduje, aby se vybral
mnozinovy doplnek. Priznejme si, ze klasicke Bstromy na tohle stavene
nejsou (pomahaji co nejrychleji najit fyzicke umisteni zaznamu se znamou
hodnotou, ale u NOT IN ji predem neznate, takze ji nejprve musite
precist z tabulky a pak teprve vyhodnotit, jestli podminku splnuje),
takze pouziti Bstromoveho indexu nad tabulkou TableA je plytvanim casem
potrebnym ke cteni indexu. Pokud tedy PostgreSQL implementuje indexy
jako Bstromy, tak mu nic jineho nezbyva.
Nyni k tabulce B. Z ni musite precist vsechny hodnoty daneho sloupce.
Tady to jiz silne zavisi na implementaci. Bud ma PostgreSQL dostatek
fistrona a rekne si, ze zkonstruovat seznam vyskytujicich se hodnot v
nejakem ZAINDEXOVANEM sloupecku je jednodussi prolezenim indexu nez
prolezenim tabulky, nebot index obvykle zabira mene diskovych bloku. Ale
pokud PostgreSQL dostatek fistrona nema (doufam, ze me Karel Zak nebude
kamenovat za takove kacirstvi), tak prochazi tabulku.
Podle informaci, se kterymi jste se podelil, tezko rici, jaky je ucel a
k cemu ma ten select presne slouzit. Na prvni pohled to totiz vypada, ze
prapricina vseho je ve spatnem navrhu datoveho modelu.
Jan Serak
Další informace o konferenci Test