Vlákno názorů k článku Čtení prováděcích plánů v PostgreSQL od Pavel Císař - Opravdu by mě zajímalo, kde jste přišel k...

Opravdu by mě zajímalo, kde jste přišel k informaci že Firebird (a navíc jen ve verzi 1.5) nezohledňuje při výběru prováděcího plánu náklady na zpracování indexů.

Je to už doba, ale vybavuji si dotazy ve Firebird konferencích ohledně blokování index. scanu na malých taulkách.

Škoda že si nevybavujete spíše ty odpovědi :-)

Firebird samozřejmě vždy zohledňoval náklady na zpracování indexu. Ono by to bylo dost divné zohledňovat náklady na čtení dat ale už ne indexů, a takového opomenutí by si za těch více než 20 let jistě někdo z vývojářů všiml :-) Pravdou ovšem je, že Firebird zdědil poměrně hrubý vzorec na výpočet nákladů, takže ho bylo nutné zpřesnit, a do verze 2.0 neměl statistiky pro částečné klíče kompozitních indexů (a doposud nemá histogramy). Rovněž se vylepšovalo vyhodnocování vhodnosti indexů a optimalizátor obecně, a všechny tyto úpravy vskutku započaly s verzí 1.5, takže právě v této době byla v konferencích spousta dotazů na detaily optimalizace.

Problémy s optimalizátorem má ovšem každá databáze, protože cost-based optimalizace není dokonalá (o rule-based nemluvě), takže frekvenci dotazů ani existenci problémových oblastí nelze považovat za důkaz absence optimalizace :-)

Bohužel ty odpovědi si fakt nepamatuji - verze Fb 1 a 1.5 mám spojené se slabší optimalizací, a verze řady dvě jako verze, kde tento problém byl nějak vyřešen. Absolutně souhlasím, že problémy s optimalizací jsou všude, včetně PostgreSQL - a řeší se, a asi se ještě budou dlouho řešit. Docela mne překvapilo, kolik změn se letos udělalo na optimalizaci v pg8.4, a to se ještě nezačala řešit otázka závislých sloupců. Zrovna tak se dost překopává optimalizace v MySQL. Moje poznámka byla spíš míněna jako varování před zastaralou verzí Firebirdu, nikoliv před Firebirdem samotným.