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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
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: 416×

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: 37 | 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: 37 | 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: 37 | 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.