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