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 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 6
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
19.10. 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 25
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (74%)
 (13%)
Celkem 180 hlasů
 Komentářů: 7, poslední 19.10. 23:06
    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: 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 | 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.