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 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 1
včera 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 26
včera 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 7
3.12. 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ářů: 14
3.12. 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ářů: 25
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ářů: 15
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ářů: 5
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ářů: 1
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 774 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: PostgreSQL a optimalizace

29.6.2009 13:30 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
PostgreSQL a optimalizace
Přečteno: 468×

Ahoj, toto mi připadá poněkud zvláštní:

db_pokus=> create table dummy( number int primary key );
CREATE TABLE
db_pokus=> set enable_seqscan = false;
SET
db_pokus=> explain select number from dummy where number = 5;
                               QUERY PLAN
------------------------------------------------------------------------
 Index Scan using dummy_pkey on dummy  (cost=0.00..8.27 rows=1 width=4)
   Index Cond: (number = 5)
(2 rows)

db_pokus=> explain select 5 in ( select number from dummy );                                    QUERY PLAN
--------------------------------------------------------------------------------
 Result  (cost=100000040.00..100000040.01 rows=1 width=0)
   SubPlan
     ->  Seq Scan on dummy  (cost=100000000.00..100000034.00 rows=2400 width=4)
(3 rows)

Fakt nechápu, proč se u druhého dotazu taky nepoužije index. Abych řekl pravdu, myslel jsem, že ten optimalizátor bude o něco chytřejší. Netušíte někdo, jak by tohle řešil například Oracle? Když se zeptám, zda existuje primární klíč dané hodnoty, je přece jasné, že se k tomu dá použít index. Nebo mi něco podstatného uniká?

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

Odpovědi

okbob avatar 29.6.2009 14:36 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

aby výstup z explainu byl co k čemu, je potřeba aktualizovat statistiky. Příkaz EXPLAIN.

 

29.6.2009 15:37 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Na tomto případě statistiky nic nezmění. Pokud zakážu seqscan a optimalizátor ho i přesto použije, znamená to, že nenašel žádnou jinou možnost provedení dotazu. Tady ovšem jiná možnost zjevně existuje...

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
okbob avatar 29.6.2009 16:58 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Optimalizátor má hlavně problém s tím, že konstanta je na levé straně oparátoru IN. To je hodně netypické - osobně jsem nikdy podobný dotaz neviděl v praxi ani nic tomu podobného. V tomto kontextu se operátor IN nepoužívá. Mnohem typičtější zápis je:

SELECT EXISTS(SELECT number FROM dummy WHERE number = 5)

29.6.2009 17:44 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Ano, tohle používá index a je to bez problémů. Jen mi to připadá divné. Včem je (z pohledu optimalizátoru) tak nepřekonatelný rozdíl mezi IN a EXISTS?

Jasně, to s EXISTS je prostě vyhodnocení poddotazu, který naprosto zjevně používá index. Následuje test, zda se něco našlo. Zato verze s IN tak nějak naznačuje „napřed vem úplně všechno a pak něco porovnej“. Ale v takto triviálním případě by přece měl optimalizáotr vědět, co z vnořeného dotazu vlastně potřebuje.

Důležitým faktem je, že když SELECT uvnitř EXISTS upravím tak, aby zahrnoval úplně všechny položky tabulky, dotaz je pořád stejně rychlý a zjevně se nikde neprochází celá tabulka. Ten případ s IN je nějaký zakletý.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 14:45 cronin | skóre: 48
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace
enable_seqscan je len odporucanie pre optimalizator, presne ako je napisane v dokumentacii.
29.6.2009 15:40 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Ne, to není doporučení a dokumentace nic takového neříká. To je podmíněný zákaz. Použití seqscan je tím zakázáno v takových případech, kdy existuje jakýkoliv jiný možný plán.

Plánovač tedy vyhodnotil situaci (nesprávně) tak, že není jiná možnost než průchod celou tabulkou. Přitom je naprosto zjevné, že jiná možnost tu existuje.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 16:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace
Jde o to, jak častý je tenhle způsob zápisu, aby se vůbec vyplatilo optimalizátor dotazů naučit tenhle trik rozeznávat. Ostatně sám jste napsal mnohem průhlednější variantu toho dotazu, takže je rozumné databázi předložit právě ten dotaz, který dokáže zpracovat lépe.
29.6.2009 16:55 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

U automaticky generovaného SQL kódu se takové věci často nedají ovlivnit.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
okbob avatar 29.6.2009 16:59 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Proto je také automatické generování kódu pitomost na n-tou.

29.6.2009 17:17 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Možná, ale já o tom bohužel nerozhoduji.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 17:14 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace
Prvním krokem optimalizace automaticky generovaného SQL kódu je vypnutí jeho automatického generování…
29.6.2009 17:19 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

Ano, zejméně v případech, kdy člověk programuje například SQL terminál, že ano. :-D

No dobře, já sice nedělám SQL terminál, ale tou poznámkou jsem chtěl naznačit, že v některých situacích prostě není zbytí. Jinými slovy, dostanu nějaký SQL kód zvenčí a něco s ním mám dělat.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 17:32 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace
Pak asi zbývá jedině napsat si ten optimalizátor SQL dotazů sám. Opravdu si nemyslím, že by SQL databáze měla optimálně zpracovat libovolně zašmodrchaný dotaz.
29.6.2009 17:46 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace

No, když tu optimalizaci nezvládli autoři databáze, kteří tu problematiku znají stokrát lépe než já, pak asi není šance, že bych dokázal vytvořit nějaký optimalizátor. (Upřímně řečeno, měl bych vážný problém i s parserem.)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 19:41 cronin | skóre: 48
Rozbalit Rozbalit vše Re: PostgreSQL a optimalizace
Ale ano, je to odporucanie. Dokumentacia doslovne hovori:
Enables or disables the query planner's use of sequential scan plan types. It's not possible to suppress sequential scans entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is on.
Takze tato volba odradza planovac od volby planu s full scan-om, ale nezakazuje ho bezpodmienecne. Takze na spravani planovaca nie je nic, co by odporovalo dokumentacii. Navyse, na full scan-e nie je nic zle.

29.6.2009 17:16 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Ztracené iluze o PostgreSQL

Tak prosím, tohle je další průšvih:

db_pokus=> explain select * from dummy where number <= all ( select number from dummy );
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Seq Scan on dummy  (cost=200006967.93..1265785714.93 rows=180224 width=8)
   Filter: (subplan)
   SubPlan
     ->  Materialize  (cost=100006967.93..100011980.41 rows=360448 width=8)
           ->  Seq Scan on dummy  (cost=100000000.00..100005199.48 rows=360448 width=8)
(5 rows)

S indexem by něco takového byla prostě hračka, otázka zlomku vteřiny. Vložil jsem do tabluky dummy cca 360000 záznamů a pak jsem spustil ten dotaz. To bylo před deseti minutami a dotaz stále běží. Tedy se opravdu jedná o závažný problém plánovače.

Tohle je ale zklamání na celé čáře. K čemu je vlastně dobrý DBMS, který není schopen získat minimální prvek z indexu v logaritmickém čase??? Jasně, není tak zle, select min( number ) from dummy; je to, co ve skutečnosti chci. To funguje správně a efektivně.

Ale jak už jsem tu jednou psal: U automaticky generovaného SQL kódu prostě někdy vznikne ta výše uvedená ošklivá věc, která v podstatě pošle celou aplikaci do háje už na relativně malých datech.

Čím to může být?

  • Nějaký problém s izolací transakcí? Že by se optimalizátor bál toho vnořeného poddotazu? Zkusil jsem stejný dotaz znovu na všech úrovních, ale nic se nezměnilo. Dotaz byl naplánován vždy nejhůře, jak to vůbec šlo. (Kromě toho si myslím, že plánování dotazu vůbec nesouvisí s úrovněmi izolace.)
  • Mám snad vypnuté nějaké pokročilé funkce optimalizátoru? Myslím, že ani tady problém nebude...

Tohle je ale fakt divné. Nemáte náhodou někdo přístup k Oracle? Zajímalo by mě, jak by EXPLAIN dopadl tam.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.6.2009 17:31 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Ztracené iluze o PostgreSQL

Aha, tak teď jsem se pěkně sekl, protože ta agregační funkce vůbec nedělá totéž. Ten správný a efektivně fungující dotaz vypadá takto:

select * from dummy where number = ( select min( number ) from dummy );

A dotaz, který vede k apokalypse, vypadá takto:

select * from dummy where number <= all ( select number from dummy );

To první si optimalizátor přebere správně a funguje to efektivně, přestože je tam poddotaz. To druhé dělá (aspoň dofám) totéž, ale ještě nikdy jsem neměl trpělivost čekat, až to doběhne do konce. Tak se zdá, že PostgreSQL má problém s operacemi typu in, not in, all a any.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
okbob avatar 29.6.2009 17:47 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Ztracené iluze o PostgreSQL

Ten první dotaz postgres dokáže optimalizovat - optimalizuje se min nebo max. Ten druhý nikoliv - prostě dělá, to co mu přikazujete - porovnává záznam s každou řádkou. Bohužel pg nepoužívá informaci o tom, že sloupec je nebo není PK. Tudíž bez znalosti faktu, že number nesmí být NULL tyto dotazy nejsou totožné.

29.6.2009 17:49 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Ztracené iluze o PostgreSQL
Aby ty dva dotazy dělaly totéž, musí tam být stejný operátor (pravděpodobně tedy <=).
29.6.2009 17:38 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Ztracené iluze o PostgreSQL
Čím to může být?
Pravděpodobně nemáte zapnutou funkci „převod blbých SQL dotazů na takové, které se normálně používají“.

Nejspíš si pletete optimalizátor prováděcího plánu dotazu s optimalizátorem dotazu. To druhé asi budete muset napsat sám do toho kódu, který tyhle podivné dotazy generuje.

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.