sql >> Base de Datos >  >> RDS >> PostgreSQL

Postgresql join_collapse_limit y tiempo para la planificación de consultas

La nueva versión 9.4 de PostgreSQL (aún no lanzada al momento de escribir este artículo) agregará tiempo de planificación a EXPLAIN y EXPLAIN ANALYZE , por lo que podrá usarlos.

Para versiones anteriores, su suposición es correcta, la mejor manera de determinar el tiempo de planificación es ejecutando un simple EXPLAIN (sin ANALYZE ) y comprobando el tiempo que tardó, en psql puedes hacerlo habilitando el \timing (Generalmente hago eso en ~/.psqlrc ).

El equipo de hackers de PostgreSQL ya discutió acerca de elevarlo a valores más grandes . Pero parece que no pudieron garantizar que sería bueno para todos los casos.

El problema es que la planificación para encontrar el mejor orden de unión para N tablas toma un O(N!) enfoque (factorial). Y así, los números que suben son muy altos, puedes verlo simplemente con la siguiente 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 puede ver, con el valor predeterminado de 8, hacemos como máximo unas 40 000 comparaciones, las 10 que usted propuso hacen que vaya a 3M, que todavía no es mucho para las computadoras modernas, pero los siguientes valores comienzan a ser demasiado grandes, simplemente aumentan. demasiado rápido, el 20 es una locura (¡21! ni siquiera cabe en un número entero de 64 bits).

Por supuesto, a veces puede configurarlo en valores más grandes como 16, que podrían (en teoría) hacer hasta 20 billones de comparaciones, y aun así tener un muy buen tiempo de planificación, eso se debe a que PostgreSQL cortó algunos caminos durante la planificación y no necesita para siempre verificar todos los pedidos, pero suponiendo que siempre será el caso y establecer valores tan altos como predeterminados, no me parece un buen enfoque. Puede haber alguna consulta inesperada en el futuro que haga que se revisen todos los pedidos y luego tenga una sola consulta que apague su servidor.

En mi experiencia, asumo el 10 como valor predeterminado en cualquier instalación en buenos servidores, algunos de ellos incluso uso 12. Le recomiendo que lo configure en 10, si lo desea, y en algunos momentos, intente configurarlo más alto ( Yo no iría más allá de 12) y seguiría monitoreando (de cerca) para ver cómo se comporta.