Názory k článku
Efektivní používání PL/pgSQL

... od těchto autorů. Díky za ně! Mimochodem co Karel Žák - Žije? :-)

Ne ;-) ...nebo jo, ale dela uz 5 let neco uplne jineho nez PG. http://www.ohloh.net/accounts/kzak

Jen bych doplnil, ze ADA i PL/SQL se preklada do bytekode kteremu se rika DIANA.
Tento bytekode je sdileny a je vykonavany v kontextu session procesu, stejne jako SQL. Preklad DIANA do nativnich instrukci procesoru je mozny, ale pokud vim tak porad jeste neni v defaltu zapnuty. SQL a PL/SQL jsou dva ruzne jazyky, ktere maji kazdy svoje datove typy.

Nemáte náhodou k dispozici detailnější informace? Vše co je na netu je docela povrchní - není například jasné, jestli je DIANA spíš bytecode nebo spíše Abstract Tree.

Vzhledem k tomu jak je to stary(1984), tak bych to tipoval spis na ten AST.
Kdyz jsem to studoval, tak jsem zacal na strankach Pete Finningana
http://www.petefinnigan.com/weblog/archives/00001318.htm
http://www.petefinnigan.com/weblog/archives/00001298.htm
a nakonec jsem skoncil na nejakych cinskych webech. Samotna DIANA je podle me verejny standart. Mnoho procedur v oracle dictionary distribuovano jako DIANA bytecode nebo wrapovany PL/SQL kod. Dekompilace DIANA je zajimava pro ty kdo se zajimaji o vnitrnosti Oracle, k tomu je ovsem potreba jeste umet cinsky nebo alespon rusky.

Díky za odkazy - bohužel o vnitřku PL/SQL je toho k dispozice zatraceně málo :(

Žiji v domnění, že většina starších DBMS_ knihoven jsou napsány právě v PL/SQL a přeloženy do nativního kódu. Je to tak?

Kompilace do nativního kódu je až od verze 11.
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/tuning.htm#i48528

Ona je vubec dobra otazka co to vlasne u Oracle znamena ten "nativni kod". Kdyz porovnate obsah catproc.sql pro Linux a AIX tak se podle me moc lisit nebudou. Zadne nativni instrukne neobsahuji. Pokud jde o ulozene procedury, tak tak cely mechanismus funguje tak, ze pomoci OCI vytvorite sdilenou knihovnu .so, tu nekde zaregistrujete, listener spusti externi proces "extproc", ten nacte tu knihovnu a Oracle se bavi v extproc pres IPC. Tzn. ani kdyz si vytvorite ulozenou proceduru v Ccku tak vas Oracle nepusit do sveho adresniho prostoru a nedovoli vam znicit si vlastni databazi. Ve vysledku se muze stat, ze Java stored procedura bude rychlejsi nez "nativni".

Preklad PL/SQL do "nativniho" kodu funguje uz od verze 9i. Je to ale takova divocina, ze neznam nikoho kdo by to realne nasadil. Cely to funguje tak, ze Oracle vezme AST tree, z toho vygeneruje Cckovej zdrojak, ten zkompiluje pomoci gcc a vysledny .so si nahraje k sobe do adresare plsqllib. Od verze 11g uz to snad funguje bez externiho kompilatoru a nativni kod se uklada primo do databaze. Porad to ale jeste neni v defaultu zapnuty.

Interakce mezi PL/SQL interpretrem a enginem databaze probiha pres "well-known" konstanty. Naco jako syscally na Unixu. V oracle ma kazdy object prideleno nejake object_id a kazda tabulka ma navic segment_id. Nektera tahle IDcka jsou pevna a jsou zakompilovana do binarek a zaroven jsou ulozena v katalogu - ve zdrojacich pl/sql baliku.

Včera jsem zkoušel najít ucelenější informace o DIANě, mcode, PVT - bohužel nic moc k dispozici není (minimálně není volně na netu). Diana je něco jako serializované AST + určitá metadata - z DIANY se kód překládá do mcode, který je interpretován v jakémsi virtuálním stroji. Překlad do C ovšem není přímo z DIANy ale z mcode - pokud tomu rozumím správně, a pokud se něco nezměnilo. Tím je to o hodně rychlejší, nicméně stále by to mělo být o dost pomalejší než nativní C kód - což ovšem by pro běžné uložené procedury v PL/SQL nemělo vůbec vadit - hrdlo bývá většinou jinde.

Skvělý článek a díky za něj!

Sémantická kontrola plPgSql procedur mi je trnem v patě už dlouho a jen co se vrátím z dovolené, hned ten modul otestuji. Nedala by se sémantická kontrola spouštět už při vytváření funkce?

Aktuálně v pg není hook, který bych mohl použít pro odchycení registrace funkce - dělám na integraci lintu do core, což by se mohlo podařit, ale nejsem si jistý, zda-li se podaří prosadit důkladnější kontrolu už při registraci funkce - tím se totiž vnáší nová závislost mezi funkcemi a stále tu bude problém s polymorfními parametry.

Tak, a teraz dajte tento clanok precitat nejakemu javistovi, pre ktoreho je databaza len (s)proste odkladisko dat, dokonale zamaskovane nejakym obrORM (tm).

Dobrý den.
Hodí se mi jazyk PL/pgSQL i jako základ pro studium Oracle PL/SQL nebo doporučujete přímo školení na Oracle?
Plánuje IInfo nějaké kurzy o databázích? Nejlíp asi to Oracle. Děkuju.

ak chcete studovat Oracle PLSQL odporucam radsej pozriet dokumentaciu k plsql
na download.oracle.com - PL/SQL Language Reference (Oracle ma velmi kvalitnu dokumentaciu) + Concepts + SQL Language reference - to su zakladne prirucky, pripadne nejake knihy napr. od Stevena Feuerstein-a (aj ked niektore jeho nazory sa mi nepozdavaju celkovo su to celkom dobre knihy).

A nieco aj k architekture: Exprert Database Architecture od Toma Kyte-a.

Dalej dobre knihy su od Oracle Oaktable network.

Opatrne s knihami od Rampart-u, a pozor na rady od pana Donalda Burlesona, ktory sa na vas bude usmievat pomaly z kazdej druhej stranky - niekedy radi vyslovene skodlivo (napr. periodicky rebuild indexov a pod.)..

Oracle skolenia su celkom drahe, ak nemate co s peniazmi, tak kludne, ale na tie zaklady sa to podla mna moc neoplati - mozno nejake pokrocilejsie (Tuning, RAC a pod.)

, 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) pokial ide o novy prikaz t

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

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.

dakujem za odpoved :)