PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Postgresql join_collapse_limit e tempo para planejamento de consulta


A nova versão 9.4 do PostgreSQL (ainda não lançada no momento da redação deste artigo) adicionará tempo de planejamento em EXPLAIN e EXPLAIN ANALYZE , e assim você poderá usá-los.

Para versões mais antigas, sua suposição está correta, a melhor maneira de determinar o tempo de planejamento é executando um simples EXPLAIN (sem ANALYZE ) e verificando o tempo gasto, em psql você pode fazer isso ativando o \timing (Eu geralmente faço isso em ~/.psqlrc ).

A equipe de hackers do PostgreSQL já discutiu sobre como elevá-lo para valores maiores . Mas parece que eles não podiam garantir que seria bom para todos os casos.

O problema é que o planejamento para encontrar a melhor ordem de junção para N tabelas recebe um O(N!) abordagem (fatorial). E assim, os números do aumento são muito altos, você pode ver isso com a seguinte consulta:
$ 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)

Como você pode ver, no padrão de 8 fazemos no máximo cerca de 40K comparações, os 10 que você propôs fazem ir para 3M, o que ainda não é muito para computadores modernos, mas os próximos valores começam a ficar muito grandes, só aumentam rápido demais, o 20 é simplesmente insano (21! nem cabe um inteiro de 64 bits).

Claro, às vezes você pode definir para valores maiores como 16, que poderiam (em teoria) fazer até cerca de 20 trilhões de comparações, e ainda ter um tempo de planejamento muito bom, isso porque o PostgreSQL cortou alguns caminhos durante o planejamento e não precisa para sempre verificar todos os pedidos, mas assumindo que sempre será o caso e tornar valores tão altos o padrão, não parece uma boa abordagem para mim. Pode haver alguma consulta inesperada no futuro que faça com que ela verifique todos os pedidos e, em seguida, você tenha uma única consulta que desative seu servidor.

Na minha experiência, assumo o 10 como valor padrão em qualquer instalação em bons servidores, alguns deles até uso 12. Recomendo que você configure para 10, se quiser, e em alguns momentos, tente configurar mais alto ( Eu não iria além de 12) e continuaria monitorando (de perto) para ver como ele se comporta.