abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 15:55 | Zajímavý projekt

Vyzkoušet si příkazy a vyřešit několik úkolů lze na stránkách Commandline Challenge (CMD Challenge). Úkoly lze řešit různými způsoby, důležitý je výsledek. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.

Ladislav Hagara | Komentářů: 9
včera 17:35 | Bezpečnostní upozornění

Německá Bundesnetzagentur (obdoba českého ČTU) zakázala na německém území prodej panenky Cayla kvůli „špionáži“ dětí. Tato elektronická hračka obsahuje mikrofon, reproduktor a kameru a bezdrátové komunikační rozhraní, pomocí kterého se hračka připojuje na servery výrobce. Takovýmto způsobem může hračka pomocí umělé inteligence „odpovídat“ na dotazy dítěte. Hlavní problém bude ale asi někde jinde, podle prvotních zpráv může

… více »
Petr Tomášek | Komentářů: 25
17.2. 15:30 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že bezpečnostní experti objevili nový typ malwaru, jenž cílí na open source e-commerce platformu Magento. Malware je zajímavý tím, že se jedná o první svého druhu, jehož kód zůstává skrytý v SQL databázi zasaženého e-shopu. Škodlivý kód je volán pomocí tzv. SQL trigerru, který je spouštěn při každém vytvoření objednávky v systému.

Ladislav Hagara | Komentářů: 2
17.2. 09:00 | Nová verze

Bylo vydáno Ubuntu 16.04.2 LTS, tj. druhé opravné vydání Ubuntu 16.04 LTS s kódovým názvem Xenial Xerus. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 47
17.2. 06:00 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje tvorbě pluginů (modulů) pro bitmapový grafický editor GIMP. Pomocí pluginů lze GIMP rozšiřovat o další funkce. Implementovat lze například nové filtry nebo pomocné utility pro tvorbu animací či poloautomatickou retuš snímků.

Ladislav Hagara | Komentářů: 6
16.2. 23:32 | Komunita

Do 30. března se lze přihlásit do dalšího kola programu Outreachy, jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 30. května do 30. srpna 2017, v participujících organizacích lze vydělat 5 500 USD. Jedná se již o 14. kolo tohoto programu.

Ladislav Hagara | Komentářů: 11
16.2. 23:13 | Nová verze

Byla vydána verze 0.92.1 svobodného multiplatformního vektorového grafického editoru Inkscape. Přehled novinek v poznámkách k vydání. Řešen je mimo jiné problém s verzí 0.92, jež rozbíjí dokumenty vytvořené v předchozích verzích Inkscape. Více v příspěvku na blogu Davida Revoye, autora open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu.

Ladislav Hagara | Komentářů: 0
16.2. 16:26 | Bezpečnostní upozornění

Byla vydána verze 1.1.0e kryptografické knihovny OpenSSL. Dle bezpečnostního upozornění 20170216 byla opravena závažná bezpečnostní chyba CVE-2017-3733.

Ladislav Hagara | Komentářů: 1
16.2. 13:03 | Pozvánky

GNOME hackaton proběhne v Brně na FIT VUT v Red Hat Labu (budova Q) v pondělí 20. února od 15:00. Registrace není nutná, ale pokud dáte na FaceBooku vědět, že plánujete dorazit, pomůže to s plánováním.

Ladislav Hagara | Komentářů: 0
16.2. 13:02 | Pozvánky

Únorový Prague Containers Meetup se koná 21. února v budově MSD. Můžete se těšit na přednášky o tom, proč a jak používat kontejnery a zároveň získat zajímavý pohled na historii a budoucnost kontejnerů.

little-drunk-jesus | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 657 hlasů
 Komentářů: 52, poslední 13.2. 12:45
Rozcestník
Reklama
Štítky: není přiřazen žádný štítek

Dotaz: perzistence provadeciho planu v pgsql

7.7.2009 09:57 honza
perzistence provadeciho planu v pgsql
Přečteno: 419×

rad bych se zeptal, jak spravuje pgsql provadeci plany pri pouziti libpq. Vyuziva se pri opetovnem pouziti toho sameho dotazu jiz vyhotoveny provadeci plan.

Jsou vubec plany sdileny vice uzivateli a preziji reconnect?

Odpovědi

7.7.2009 10:16 cronin | skóre: 48
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql
Plan dotazu zavisi nielen od dotazu samotneho, ale aj nastaveni aktualnej session a aktualneho stavu databazy.
7.7.2009 16:12 dad
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

pri pouziti libpq je prece pravdepodobnost, ze dotaz bude stejny miziva. Proto bych se divil, ze by byla na backendu pro libpq realiziovana sprava jiz vytvorenych planu. Neco jineho by bylo, kdyby bylo mozno odsadit z libpq parametrizovane dotazy, ale o tom nevim.

okbob avatar 7.7.2009 16:35 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

a) pokud nepouzijete pooling, tak plany nejsou sdileny nikdy.

b) pokud chcete pouzit provadeci plan opakovane, je nutne pouzit prepared statements. Ty jsou v postgresql omezene na session - proto je nutny ten pooling, diky kteremu se jedna session pouzije opakovane.

Pavel

 

8.7.2009 11:39 Ivan
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

Pokud vim tak exekucni plany sdili jedine Oracle. Cela myslenka sdileni exekucnich planu vychazi z predpokladu, ze autor aplikace neni idiot a ze pouziva rozumne mnozstvi SQL statementu. V Oracle se rozlisuje tzv. soft parse(plan se najde podle hashe SQL v SGA) a hard parse(cely exekucni plan se vymysli a ulozi do SGA). Proti sdileni exekucnich planu mam jeden priklad z praxe. V DB je tabulka T a ma sloupce (PK1, ANAME1, AVALUE1, ..., ANAME24, AVALUE24). Inserty do teto tabulky vklada nejaky JAVA sr*c, ktery dynamicky "vymysli" SQL statement podle toho ktere sloupce jsou insertu zrovna pouzity. Hadam ze programator ktery tohle vymyslel byl na sebe hodne pysny, kdyz to odladil. Tabulka T ma 24 "atributu" => existuje 2^24 (16,7 milionu) ruznych insertu. A  LRU cache Oracle se poctive snazi udrzet exekucni plany vsech insertu, bohuzel ma SGA omezenou velikost a proto se ji to nikdy nemuze podarit a z SGA "vypadavaji" i SQL statementy, ktere by tam mely zustat. Na RACu se navic sdili exekucni plany i mezi nody, takze kazde parsovani vyzaduje komunikaci po siti mezi nody clusteru.

Na druhou stranu treba Informix exekucni plany nesdili. Kazda session si drzni svoje exekucni plany. Proti tehle strategii mam zase jiny protipriklad z praxe. Nekdo rekl JAVA programatorovi ze je dobre pouzivat prepared SQL statementy, buhuzel uz mu nikdo nerekl ze pokud pouzitje Prepare, tak taky musi pouzit Release. Jinak si bude Informixova session pamatovat exekucni plan dotazu navzdy. JAVA programator predpokladal ze uvolneni prostredku za nej vyresi GC. Cim system bezi dele, tim vice pameti zabiraji exekucni plany jednotlivych SQL dotazu. Za tyden je to cca 8GB RAM. Ten system stal spoustu penez, vsechno je navrzeno aby to bylo vysoce dostupne a presto je to potreba kazdy tyden restartovat.

Prvni priklad by v pohode fungoval na Informixu a ten druhy zase na Oracle. Takze sdileni exekucnich planu neni zadna vyhra, casto to beh zrychli ale nekdy to muze spusobit spoustu problemu.

 

 

8.7.2009 18:25 podlesh | skóre: 38 | Praha
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql
DB2 také ukládá zkompilované dynamické příkazy v cache (package cache).

Velmi užitečná věc, nějak se mi nezdá že by to opravdu žádná jiná databáze neměla (tedy kromě MySQL). Prakticky to lze vidět právě v případě, kdy někdo tu cache zahltí generováním obrovského množství různých dotazů (nejhorší mor je lepení hodnot přímo do dotazu místo použití otazníku).
8.7.2009 18:27 podlesh | skóre: 38 | Praha
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql
Z toho také plyne, že pokud by se původní dotaz týkal DB2, tak by odpovědi byly všechny ano. Bohužel s postgresem neporadím.
14.7.2009 16:42 z/OS
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql
DB2 9.7 LUW umi volitelne prevadet dotazy na jejich otaznikove varianty aby se sdilena cache pro dotazy lepe vyuzila.
15.7.2009 09:41 podlesh | skóre: 38 | Praha
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql
More Efficient Queries with Literals: DB2 has always made good use of resources by not needing to recompile new queries that are identical to queries already in the package cache. It now considers queries that are the same except for literals in the predicate (where clause) to also be identical. This is especially useful in OLTP workloads that execute lots of queries with different predicate literals because it can significantly reduce the amount of prepare time.
Pěkné. Je vidět že v IBM konečně myslí i na PHPkáře.

Ale na vynalézavé javisty si nikdo nepřijde - stačí generovat proměnný počet otazníku ;-)
okbob avatar 8.7.2009 19:35 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

V postgresu se jednu chvíli uvažovalo o tom, že by se sdílení plánů zavedlo - prakticky v tom není žádný problém - uložit plán lze (prepared statement) a sdílená cache je v pg k dispozici také. Proti byli někteří významní DBA, kteří tvrdí, že použítí sdílených plánů může vést k horšímu výkonu - v případě cost based optimalizace. V tomto případě optimální plán se mění v závislosti na parametrech. Pokud by docházelo k implicitnímu použítí plánů z cache, tak by nepochybně byly některé prováděcí plány neoptimální. Něco jiného je rule based optimalizace. Tam je optimální plán nezávislý na parametrech a tudíž snadno může být sdílen. Jako větší zlo se považuje špatný prováděcí plán než opakované provádění optimalizace. Proto přístup pg je takový, že plán není uložen v cache, ale do cache se ukládají všechny informace, které jsou potřeba pro vygenerování plánu - tudíž opakované generování plánu je velice rychlé - samosebou pomalejší než načtení plánu z cache. Pokud by pak bylo potřeba skutečně bombardovat server SQL příkazy, pak lze použít prepared statements.

Mimochodem MS SQL Server také sdílí prováděcí plány.

 

8.7.2009 20:56 honza
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

dekuji za reakce a dodam kratke vysvetleni. Ve firme se uvazuje o prechodu ze stareho servru informix (7.x) na neco noveho. 

Dosavadni software vyuzivalo ESQL a jak ze starych casu znamo, je v prelozenem kodu jiz vytvoreny plan 'obsazen'. Nenastava tedy problem, ze by se musela provadet sprava vyhotovenych planu. ESQL-statements jsou samozrejme svou podstatou jiz 'prepere', o to se staraji jiz nutnost pouziti host-variables.

Pri analyze pgsql jsme se puvodne domnivali, ze prepare statements je mozno pouzit pouze na urovni SPI. Nyni po studiu nekterych clanku (napr. p.Zak/root) a po prispevku pana Stehuleho zde tomu rozumim tak, za i libpq podporuje prepare-statements, _ale_ o spravu planu se musi starat uzivatelske software (pgsql databaze to nedela sama).

Mimojine, na libpq jsme prisli oklikou, protoze jsme samozrejme chteli zkusit vyuzit ESQL podporu v postgresql a k nasemu prekvapeni ta implementace vubec nepracuje tak, kak se to drive delalo (prelozeny kod plan neobsahuje) - a dalsi analyzou jsme zjistili, ze ESQL implementace v pgsql vyuziva libpq, tam je mozno tedy vyuzit prepare statement ale v kratkosti jsme nikde nenasli tu spravu tech planu v ESQL interfaci.

Podle prispevku pana Stehuleho to vypada, ze by nase starost, aby nas kod byl jiz 'hotovy k pouziti' , neni tak opravnena, podle jinych prispevku zde to ovsem jine databaze delaji. Takze vlastne zase clovek nevi co :-)

Rad bych se ohledne pgsql zeptal jeste na jednu vlastnost. V informix bylo mozne napr. v SELECT statement pouzit jako host_variable normalni C-strukturu. Tato struktura byla samozrejme 'chytre' vytvorena tak, ze jeji prvky byly prave obsahy nacitanych udaju z tabulky. (priklad - select a,b,c,d from t.x ...) SELECT statement tedy nacetl najednou vsechny udaje (obsah sloupcu a,b,c,d do prvku struktury) bez toho, aniz by se musel v nejake smycce dodany vysledek rozhodit  do jednotlivych promenych.

Existuje nejaky podobny mechanismus v pgsql.

okbob avatar 9.7.2009 07:27 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: perzistence provadeciho planu v pgsql

Já jsem nikdy nedělal ani s Informixem a stejně tak esql, takže Vám moc neporadím. Nevím proč byste ale v esql pg měli si explicitně hrát s prováděcími plány - důležitý je SQL příkaz - prováděcí plán se vygeneruje až když je nutné a na straně serveru. Správu plánu řešíte pouze u dynamického SQL.

Z konference pg je ovšem znát, že lidi co psali v esql na informixu požívají esql i na PostgreSQL. Pro pochopení věcí bych ale doporučoval dočasně zapomenout na Informix. Řekl bych, že zdrojáky esql budou stejné - vlastní implementace, resp. to co vyleze pak dost jiné.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.