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 19:55 | Zajímavý článek

Byly zveřejněny (pdf) podrobnosti o kritické bezpečnostní chybě CVE-2017-12542 v HPE iLO 4 (Integrated Lights-Out), tj. v proprietárním řešení společnosti Hewlett Packard Enterprise pro vzdálenou správu jejich serverů. Bezpečnostní chyba zneužitelná k obejití autentizace a k vzdálenému spuštění libovolného kódu byla opravena již v květnu loňského roku ve verzi 2.53.

Ladislav Hagara | Komentářů: 0
dnes 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
dnes 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
dnes 16:11 | Komunita

Svobodný unixový operační systém FreeBSD slaví 25 let. Přesně před pětadvaceti lety, tj. 19. června 1993, byl vybrán název FreeBSD.

Ladislav Hagara | Komentářů: 0
dnes 15:11 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Nadace Blender Foundation informuje, že od společnosti Google dostala šestistránkový návrh nové smlouvy (pdf). Zdá se, že podmínkou další spolupráce je zapnutí reklam na kanálu, tj. zpeněžení obsahu.

Ladislav Hagara | Komentářů: 19
dnes 01:55 | Nová verze

Byla vydána verze 1.13 multiplatformního open source textového editoru Brackets (Wikipedie, GitHub). Přehled novinek v oficiálním oznámení a v poznámkách k vydání. Brackets je nově dostupný také jako balíček ve formátu Flatpak z oficiálního repozitáře Flathub.

Ladislav Hagara | Komentářů: 3
včera 18:44 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Důvody jsou zatím nejasné. Pravděpodobně chyba YouTube. Dění lze sledovat na Twitteru Tona Roosendaala.

Ladislav Hagara | Komentářů: 18
včera 17:55 | Zajímavý software

Na GitHubu byly pod open source licencí LLVM zveřejněny zdrojové kódy překladače programovacího jazyka C++ Zapcc vycházejícího z Clangu/LLVM. Překlad pomocí Zapccu je díky lepšímu kešování obvykle několikrát rychlejší než překlad pomocí Clangu. V březnu loňského roku byl vydán Zapcc ve verzi 1.0.

Ladislav Hagara | Komentářů: 0
včera 17:22 | Pozvánky

Červnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 6. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: F-Droid, aneb svobodný software do vašeho mobilu. Kromě toho budou k vidění i vývojové desky HiFive1 se svobodným/otevřeným čipem RISC-V.

xkucf03 | Komentářů: 1
15.6. 22:44 | Zajímavý článek

Na blogu projektu NeoPG (GitHub), kryptografického softwaru vycházejícího z GnuPG, byly zveřejněny 4 příspěvky detailně popisující aktuální bezpečnostní problémy v GnuPG a souvisejících softwarových produktech. V prvním příspěvku je ukázáno, že je možné vytvořit zprávu, o které budou Earlybird, Evolution, Mutt nebo Outlook tvrdit, že jí dešifrovali a přitom ale zpráva vůbec zašifrována nebyla. V druhém příspěvku je popsána

… více »
Ladislav Hagara | Komentářů: 7
Jak čtete delší texty z webových stránek?
 (78%)
 (22%)
 (4%)
 (7%)
 (2%)
 (11%)
Celkem 212 hlasů
 Komentářů: 36, poslední včera 21:16
    Rozcestník
    Š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: 49
    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 | Freiburg im Breisgau
    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 | Freiburg im Breisgau
    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 | Freiburg im Breisgau
    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.