Postgresql join_collapse_limit и време за планиране на заявката

Новата 9.4 версия на PostgreSQL (все още не е пусната към момента на писане) ще добави време за планиране в EXPLAIN и EXPLAIN ANALYZE и така ще можете да ги използвате.

За по-стари версии предположението ви е правилно, по-добрият начин да определите времето за планиране е като изпълните просто EXPLAIN (без ANALYZE ) и проверка на времето, което е отнело, в psql можете да го направите, като активирате \timing (Обикновено правя това в ~/.psqlrc ).

Екипът на хакерите на PostgreSQL вече обсъди повишаването му до по-големи стойности . Но изглежда, че не могат да гарантират, че ще е добро за всички случаи.

Проблемът е, че планирането за намиране на най-добрия ред на присъединяване за N таблици приема O(N!) (факторен) подход. И така, числата, които повишават, са много високи, можете просто да видите това със следната заявка:

$ 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)

Както можете да видите, при 8 по подразбиране правим най-много около 40K сравнения, предложените от вас 10 го карат да отиде до 3M, което все още не е много за съвременните компютри, но следващите стойности започват да стават твърде големи, просто се увеличават твърде бързо, 20 е просто лудост (21! дори не се побира в 64-битово цяло число).

Разбира се, понякога можете да го зададете на по-големи стойности като 16, които (на теория) биха могли да направят до около 20 трилиона сравнения и все пак да имате много добро време за планиране, това е защото PostgreSQL прерязва някои пътища по време на планиране и не се нуждае довинаги проверява всички поръчки, но ако приемем, че винаги ще е така и направим такива високи стойности по подразбиране, не ми изглежда като добър подход. В бъдеще може да има някаква неочаквана заявка, която да я накара да премине към проверка на всички поръчки и след това да имате само една заявка, която да попречи на сървъра ви.

Според моя опит приемам 10 като стойност по подразбиране при всяка инсталация в добри сървъри, някои от тях дори използвам 12. Препоръчвам ви да го зададете на 10, ако желаете, и понякога опитайте да го зададете по-високо ( Не бих надхвърлил 12) и продължавам да наблюдавам (внимателно), за да видя как се държи.