Názory k článku
PostgreSQL: připravené dotazy a oddělení dat od dotazů

...a to uz hoooodne let. a nejen pro postgresql, ale i pro jine sql servery. bude to ted nejak vyrazne rychlejsi?

Jak je na zacatku clanku receno, DBI apod jsou klientske udelatka zjednodusujici programatorovo praci. Z hlediska komunikace se serverem nic neresi.

Pokud vas dotaz travi 99% dotazu praci s diskem tak to rychlejsi nebude :-) Bude to vsak bezpecnejsi a primocarejsi nez resit to na strane klienta.

to co patrne predrecnik nepochopil je, ze se nemusi volat parser pro kazdy SQL prikaz. Co jsem ja nepochopil, jak to server pozna. Je to tim, ze kdyz jsou v prikazu ty $1,$2... tak si to server po prvnim volani parseru automaticky ulozi, nebo se to musi nejak jinak zvlast rici?

Pro znasilneni SQL db jako isam-databaze je to senzacni novinka. Dekuji.

Server to pozna snadno, protoze o to aby dotaz byl ulozen zadate pomoci "PREPARE" a nebo pomoci specialniho rozhrani klientske knihovny.

Koukam, ze tendle clanek jsem napsal nejak malo pochopitelne a nebo lidi moc rychle ctou :-)

Životnost dotazu v paměti je dána délkou trvání vaší session se SQL serverem. Jinak řečeno po odhlášení a ukončení spojení jsou z paměti serveru odstraněny i všechny uložené dotazy.
- Je docela skoda, ze dotazy nejsou perzistentni skrz databazove sessions. I kdyz se webovy server nepripojuje znova pri kazdem vyrizovani stranky, prece jenom se v zavislosti na provozu muze pripojovat relativne casto. Navic, dotaz musi byt pripraven pro kazdou jeho instanci znova... Ze by autori cashovali pripravene dotazy na zaklade dvojice (syntax, user), nikoliv semantiky dotazu ? (select * from my_view nemusi nutne delat pro ruzne uzivatele to same)

PG pochopitelne podporuje VIEW, ktera jsou persistentni a jedna se o neco naprosto jineho nez PREPARE/EXECUTE. PG ma pro kazde spojeni samostatny proces a cache je v jeho vlastni pameti(tedy nezdilena) a ulozena jak je v _clanku_ reseno podle nazvu dotazu tedy nic ohledne syntaxe a username.

Ano, nevsiml jsem si poradne 'PREPARE myquery (text) AS ...'.
Presto bych uvital vysvetleni, co je hlavni pricinou toho, ze pripravene dotazy NEJSOU sdileny v shared memory, aby mohly byt vyuzity v ostatnich sessions. Napriklad 'PREPARE [PUBLIC|USER] myquery...' - pripraveny dotaz by bylo mozno deklarovat jako verejny nebo platny pouze pro stejneho uzivatele.
Postgresi views znam, uvadel jsem jen jednoduchy priklad, kdy syntakticky totozny dotaz, konkretne retezec 'select * from myview;' nemusi nutne vracet stejna data pro ruzne uzivatele, i vysledek optimalizace tohoto dotazu muze na uzivateli zaviset.

To vim naprosto presne protoze prvni experimentalni implementaci PREPARE/EXECUTE jsem psal ja a ukladani do sdilene pameti podporovala. Ale... bylo to vyhodnoceno jako neco kde vyhody jsou mensi nez problematicnost implementace. PG neni threadova aplikace takze se pouziva sdilena pamet (IPC) a to je dost osemetna vec je nutne resit veci jako co delat kdyz tato pamet dojde apod. Z dlouhodobeho hlediska se doslo k tomu, ze radeji nez pouzivat pro podobne cache sdilene pameti tak radeji udelat persistentni servery (neco jako apache) ktere po ukonceni spojeni ziji dal a cekaji na dalsi session.

jsou rozhodne dobry napad, pokud jejich startovani zabere hodne casu. Spise by pomohly v pripadech, kdy se casto zakladaji nove db sessions. Uz vidim ten radek v postgres.conf:
spare_postmasters=2
Ale mozna by to byla skoro zbytecna prace - existuji demoni provozujici connection pooling, ty udrzi prislusny pocet postmasteru pri zivote. Nemam je ale prozkoumane.
Te sdilene cache pripravenych dotazu je, myslim, skoda...

Tohle se prece resi stored procedurama, to sou Microsofti SQL server a Oracle jediny db enginy co je maj? Nejenom ze resi problem kompilace a presistence execution planu, ale da se tim i docela dobre ohlidat bezpecnost, kod pracujici s databazi nema prava na nic jinyho nez na spousteni urcenych sprocs. Zadny prava na zmeny nebo mazani zaznamu v tabulkach, jen na spusteni procedur co to delaj (v teorii hlidane a bezpecne).

PostreSQL ma tyhlety veci v podstate taky, a docela dobre, i kdyz (zatim) bez featur jako jsou packages v Oraclu.
Stored procedures ale neresi napr. nasledujici scenar: Instance Apache se kazda pripojuji do db samostatne. Webova stranka je navrzena tak, aby v ni uzivatel mohl data prohlizet po strankach - to znamena, ze ruzne instance Apache spousteji identicke selecty, akorat s jinymi parametry. Nemyslim si, ze na tohle by bylo vhodne psat proceduru. Ten select muze byt vytvoren vicemene ad hoc, jenom se vi, ze ted se pravdepodobne bude nekolikrat opakovat v obecne ruznych db sessions.

No treba oracle to resi, tak, ze dotazy jsou perzistentni mezi sessions a muze je pouzivat i vice uzivatelu najednou. Oracle rozlisuje tzv. soft a hard parse. Soft parse vlastne akorat nalezne parsovany a optimalizovany dotaz ve sdilene pameti.

SP je neco, co je eventuelne vhodne pouzit v 'projektech'. Tedy ulohach, kde se sejdou preskoleni ucitele, jaderni fyzici, matematici a zemedelsti inzenyri a bastli mesice na ruznych SQL prikazech odpovidajice db-navrhu.

To co popisuje p. Zak cili vice na skupini lidi, kteri se snazi vyrabet softwarove produkty a neni jim cizi slovo modularita.

SP zrovna tak jako komplikovane SQL prikazy znamenaji totiz smrt modularity.

To by mne zajímalo proč? Naopak. Díky SP mohu provést ještě lepší dekompozici. Schopných programátorů jsem v Čechách moc neviděl, a je mi úplně jedno, co dělali. Zato bastlířů, ktěří všemu rozumněli a na všechno měli názor jsem viděl dost. Až na MySQL jsou si všechny db skorem rovny, pominu-li hiearch. dotazy atd. Netuším, proč by měl být komplikovany SQL dotaz narušovat modularitu aplikace. Jak to spolu souvisí?

netrivialni problemy (napr. kontrola schopnosti plnenei dodavky (=ability to deliver) v nejakem vyrobnim informacnim systemu je nutno realizovat pomoci komplikovaneho SQL prikazu. V tomto prikazu jsou schovany jaksi automaticky 'podprikazy' napr. pro zjistovani stavu na sklade. Modularni system ma pro zjistovani stavu na sklade vlastni funkci, ktera muze byt dokonce dodana externim dodavatelem.

Pro jiny informacni system, ktery pouziva jiny skladovy system, je zjistovani schopnosti realizovat dodavku stejne, vymeni se pouze ta zjistovaci funkce pro stav na sklade. U SQL systemu je nutno prekopat SQL prikazy. To NENI modularita.

Jenom prosim at nikdo nerika, ze by to slo pomoci SP. Pak musi totiz prozradit, jestli bude ta modularni SP pro skladovy stav ma byt pro informix 7.1, oracle 8.1.15 nebo kterou to db a jeji verzi. A co kdyz nekdo pouziva mysql?

Na to odpovím jen tak, že člověk by měl být realista. A modularita odsuď, podsuď. Pokud dekomponujete aplikaci až na takové střípky, tak samosebou, můžete každý střípek nahradit. Ale dost deklasujete výkon db, komplikujete návrh. Uvažovat o zastupitelnosti Oraclu a MySQL je mírně řečeno nerealistické. Před dvěma lety jsem dělal na větším projektu, který se ladil na mssql. Nesměli se používat SP, protože by se to pak nedalo použít na Oraclu. V okamžiku, kdy byla větší zátěž se stejně musely SP použít, protože to bylo pomalé při operacích se stromy. A pro Oracla se to v životě nepoužilo. Jiný příklad ze života. Proslavené ForkFlo FileNetu. Bylo navrhované kdysi pro nějakou prehistorickou databázi. Datové struktury jsou stejné pro Oracle i MsSQL. Nic pomalejšího jsem v životě neviděl. Ta debata už tu byla. Jsou nástroje, jak mohu odstínit specifika databází na úrovni knihoven.

Je to spíš politická úvaha než cokoliv jiného. Zda-li naplno využít možnosti, které jsou k dispozici a stanu se závislákem nebo si budu držet odstup.

A co pohledy? Ty by mely umet presne totez, ne? Nevite nekdo jestli jejich pouziti se pojevi pozitivne na vykonu?

Neni to tak docela totez. Shoda je v tom, ze jak view, tak prepared statement si jednou zpracuji plan vyhodnoceni a pak jej pouzivaji. Prepared statement ale ma navic parametry, ktere se dosazuji az pri vyhodnoceni.

Jen me napadlo, ze hodnoty parametru taky muzou mit vliv na optimalizaci. Napr. mam tabulku neceho, co je rozdelene do kategorii a kdyz dam ve WHERE podminku na category=10, vim ze statistik nebo indexu, ze mi to zredukuje 100000 zaznamu na 100, ale treba category=1 je castejsi a zredukuje mi to na 10000 zaznamu; pak plan vyhodnoceni dotazu (s dalsimi podminkami, joiny apod.) se muze podle hodnoty parametru lisit. Prepared statementy ale na teto urovni optimalizovat nemohou, protoze jeste nevi, jaka bude hodnota pro category.

Dalsi podobna vec je, ze se data v prubehu session mohou zmenit natolik, ze puvodne pripraveny plan se stane neefektivni.

Nebo se mylim?

Mate pravdu, ale zde nejde jen o parametry ale obecne o dalsi veci, o ktery optimizer nic netusi jako treba vysledky volani funkci. WHERE id=func() ...