sql >> Databáze >  >> RDS >> PostgreSQL

Postgresql join_collapse_limit a čas pro plánování dotazů

Nová verze PostgreSQL 9.4 (v době psaní tohoto článku ještě nevydaná) přidá čas na plánování do EXPLAIN a EXPLAIN ANALYZE , a tak je budete moci používat.

U starších verzí je váš předpoklad správný, lepší způsob, jak určit plánovací čas, je provedením jednoduchého příkazu EXPLAIN (žádné ANALYZE ) a kontrola času, který to trvalo, v psql můžete to udělat povolením \timing (Obecně to dělám na ~/.psqlrc ).

Tým hackerů PostgreSQL již diskutoval o zvýšení hodnoty na vyšší hodnoty . Ale vypadá to, že nemohli zaručit, že to bude dobré pro všechny případy.

Problém je v tom, že plánujeme najít nejlepší pořadí spojení pro N tabulky mají O(N!) (faktoriální) přístup. A tak, čísla navýšení jsou velmi vysoká, to můžete jednoduše vidět pomocí následujícího dotazu:

$ SELECT i, (i)! AS num_comparisons FROM generate_series(8, 20) i;
 i  |   num_comparisons   
----+---------------------
  8 |               40320
  9 |              362880
 10 |             3628800
 11 |            39916800
 12 |           479001600
 13 |          6227020800
 14 |         87178291200
 15 |       1307674368000
 16 |      20922789888000
 17 |     355687428096000
 18 |    6402373705728000
 19 |  121645100408832000
 20 | 2432902008176640000
(13 rows)

Jak vidíte, při výchozí hodnotě 8 provádíme nanejvýš asi 40 000 srovnání, 10, které jste navrhli, vede k 3M, což pro moderní počítače stále není příliš mnoho, ale další hodnoty začínají být příliš velké, jen se zvyšují. příliš rychlé, těch 20 je prostě šílené (21! se ani nevejde na 64bitové celé číslo).

Samozřejmě, někdy to můžete nastavit na větší hodnoty, jako je 16, což by (teoreticky) mohlo vytvořit asi 20 bilionů srovnání a stále mít velmi dobrý čas na hoblování, protože PostgreSQL při plánování zkrátil některé cesty a nepotřebuje až vždy zkontrolovat všechny objednávky, ale za předpokladu, že to tak bude vždy a nastavit tak vysoké hodnoty jako výchozí, mi nepřijde jako dobrý přístup. V budoucnu se může objevit nějaký neočekávaný dotaz, který povede ke kontrole všech objednávek, a pak budete mít jeden jediný dotaz, který zničí váš server.

Podle mých zkušeností předpokládám, že 10 je výchozí hodnota na každé instalaci na dobrých serverech, některé z nich dokonce používám 12. Doporučuji vám nastavit ji na 10, pokud chcete, a někdy ji zkusit nastavit vyšší ( Nešel bych dále než 12) a průběžně (pečlivě) sledoval, jak se chová.




  1. EclipseLink selže při načítání skalární booleovské hodnoty

  2. PHP a MySQL:Zobrazit SUM of Something, klasifikováno podle odlišné kategorie

  3. Jak exportovat miliony řádků z MySQL do CSV přes PHP bez vyčerpání paměti?

  4. Chyba při aktualizaci spouštěče