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

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

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.

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.

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.

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?

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 :)

dakujem za odpoved :)