Vlákno názorů k článku Efektivní používání PL/pgSQL od Radoslav Golian - Omylom sa mi podarilo submitnut nedokoncenu reakciu.. zaujala ma...
-
Radoslav Golian (neregistrovaný)
Omylom sa mi podarilo submitnut nedokoncenu reakciu..
zaujala ma veta:
"FOR EXECUTE nepoužívá cache pro prováděcí plány a tudíž prováděcí plán bude vždy odpovídat hodnotám parametrů"
to naozaj takto funguje v postgre? vzdy sa vytvara novy exekucny plan pri pouziti dynamickeho SQL? Nie je to prilis narocne?Som sice oraclista, ale celkom by ma to zaujimalo :)
V Oracle funguje spracovanie prikazu nasledovne
1) pri dynamickom sql sa vzdy vykona tzv. soft parse - spravi sa hash + overia sa prava a pod.
2) ak uz je plan v cache tak sa pouzije existujuci plan
3) ak nie je plan v cache tak sa vykona fyzicka optimalizacia, tj. hladaju sa a ocenuju exekucne plany, skusaju sa kadejake transformacie a pod., co je velmi narocna operacia..1-3 = tzv. hardparse, jedna z najhorsich co mozete oracle databaze urobit je nepouzit viazane premenne (napr: "select ... where id =" + $id) - pre oracle je to vzdy iny selekt, takze vzdy robi hardparse..
ak by sa pouzila viazana premenna select ... where id = :1, tak by to bol vzdy den isty selekt ak by to slo cez execute immediate tak by sa robil len soft parse..
Takze toto v postgre funguje inak? nie je rozdiel medzi konkatenaciou a medzi viazanymi premennymi z hladiska vykonosti? (jasne ze je rozdiel z bezpecnostneho hladiska) vzdy sa pocita plan?
2)
Takze postgre ma tiez bind-peeking? tj optimalizuje plan podla hodnoty viazanej premennej ktora bola v selekte pocas hardparsu (prvy krat ked ten do db prisiel)dakujem za odpovede
-
Radoslav Golian (neregistrovaný)
Tu 2) mozete ignorovat mal by som pozornejsie citat :) je to oproti priemernym hodnotam.. - tie priemerne hodnoty su zo statistik k danej tabulke? zbiera postgre histogramy (kvoli distribucii hodnot v stlpcoch)
v oracle je najlepsie ten problem s filtrovanim riesit nasledujucou fintou:
...
if param is null then
l_dynamic := l_dynamic || ' AND (1=1 OR :param is null)' -- tautologia, len kvoli zachovaniu statickeho poctu viazanych premennych
else
l_dynamic := l_dynamic || ' AND (column = :param)'
end if;
...
execute immediate l_dynamic using ... in param ...;obidva tie selekty v clanku by sli v oracle vzdy fullscanom..
Celkom poucne vediet taketo rozdiely :) este raz vdaka :)
-
Při dynamickém SQL se prováděcí plán dotazu neukládá do cache. PostgreSQL nepoužívá plan cache ani pro běžné dotazy jako např. MSSQL. Pokud chceme používat plán opakovaně, tak je nutné použít explicitně PREPARED STATEMENTs.
Generování prováděcích plánů je náročná úloha - při nižších počtech tabulek ale dostatečně rychlá (a při větším počtu nastupují heuristiky - optimalizace založené na GA), takže opakované vytvoření plánu není tragédie. Záleží na poměru doby vytvoření plánu vůči celkové době provedení dotazu. Vytvoření plánu trvá běžně cca 1-10 ms, což v poměru k době trvání dotazu 10-100 ms (případně vteřiny až sec) většinou je zanedbatelné. Znovupoužití plánu představuje docela velké riziko - které se eliminuje verifikací parametrů, což v PostgreSQL není (možná bude), a v tuto chvíli je bezpečnější plán vytvořit znovu vůči aktuálním parametrům. Jinak planner v PostgreSQL je jednodušší (i díky tomu, že není podporován ROLAP), takže je o něco rychlejší.
Je to nevýhodné, pokud máte aplikaci, která bombarduje databázi množstvím jednoduchých opakujících se dotazů. V PostgreSQL je nutné v této situaci použít prepared statements. Taková situace ovšem dost často vzniká z ISAM přístupu - což je chyba (a pak pokud je to možné, je vhodné přesunout kód z klienta do SP, čímž se zároveň řeší znovupoužítí plánů.
Vázané parametry samy o sobě v PostgreSQL nemají vliv na výkon (v podobě dohledání dotazu v cache (plan cache se implicitně používá pouze pro SP)). Pozor - v některých prostředích a konfiguracích mají vliv na výkon - třeba JDBC - ale to je otázka JDBC nikoliv Pg. Parametrizace dotazů je v pg primárně otázkou bezpečnosti - sekundárně čitelnosti kódu v aplikaci.
Pg si ve statistikách ukládá histogram hodnot a n nejčastějších hodnot.
