Novedades del planificador de consultas de Postgres 16

Novedades del planificador de consultas de PostgreSQL 16

• PostgreSQL 16 introduce muchas mejoras en el planificador de consultas, lo que permite que muchas consultas SQL se ejecuten más rápido que en versiones anteriores.
• Estas mejoras del planificador pueden verse en las notas de la versión de PG16, pero como cada lanzamiento de PostgreSQL incluye muchos cambios, es difícil ofrecer una explicación detallada de cada uno.
• En esta entrada de blog se ofrece un análisis profundo de 10 mejoras realizadas en el planificador de consultas de PostgreSQL 16, junto con comparaciones entre la salida del planificador de PG15 y PG16 y ejemplos de los cambios.

10 mejoras en el planificador de consultas de PostgreSQL 16

• Ordenamiento incremental: introducido por primera vez en PostgreSQL 13, el ordenamiento incremental aprovecha cuando parte del conjunto de resultados ya está ordenado por una o más columnas iniciales, y solo ordena las columnas restantes.
• Agregación usando datos ordenados: el planificador de consultas de PostgreSQL 16 ahora intenta formar planes que suministren filas al nodo de agregación en orden ya clasificado.
• Memoización: introducido por primera vez en PostgreSQL 14, el nodo de plan de memoización funciona como una capa de caché para evitar búsquedas de valores duplicados.
• Anti join: PostgreSQL 16 permite aplicar hash a la tabla más pequeña al realizar un anti join.
• Parallel hash join: PostgreSQL 16 admite parallel hash join para los tipos de join FULL y RIGHT.
• Optimización de funciones de ventana: PostgreSQL 16 permite usar funciones de ventana más rápidas al usar el modo ROWS en lugar del modo RANGE.
• Optimización de funciones de ventana siempre crecientes: PostgreSQL 16 amplía las optimizaciones para funciones de ventana como ntile(), cume_dist() y percent_rank().
• Eliminación de joins en tablas particionadas: PostgreSQL 16 permite la optimización de eliminación de LEFT JOIN en tablas particionadas.
• Uso de Limit para consultas DISTINCT: el planificador de consultas de PostgreSQL 16 no incluye un nodo de plan para eliminar duplicados en los resultados cuando puede detectar que todas las filas contienen el mismo valor.
• Relajación de reglas para Merge Join: el planificador de consultas de PostgreSQL 16, al considerar Merge Join, verifica que al menos una columna inicial esté ordenada correctamente en lugar de exigir una coincidencia exacta del orden de las filas.

La opinión de GN⁺

• Las mejoras del planificador de consultas en PostgreSQL 16 desempeñan un papel importante en el aumento del rendimiento de la base de datos. En particular, funciones como el ordenamiento incremental y la memoización permiten ejecutar consultas complejas de forma más eficiente.
• Estas mejoras serán muy útiles para desarrolladores y administradores de bases de datos que usan PostgreSQL, y el aumento de rendimiento podrá notarse especialmente en sistemas que manejan grandes volúmenes de datos.
• Los continuos esfuerzos de innovación y mejora de la comunidad de PostgreSQL están impulsando el avance de la tecnología de bases de datos de código abierto, lo que brinda mejores soluciones de gestión de datos para usuarios y empresas.

[GN⁺]

Comentarios en Hacker News

• Hay quienes opinan que sería bueno que el planificador de consultas de Postgres pudiera replantear una consulta a mitad de la ejecución. Cuando falta información sobre la distribución de los datos, se puede generar un plan de consulta ineficiente, y eso puede afectar mucho el tiempo de ejecución. Si una consulta avanza más lento de lo esperado, haría falta una función que la vuelva a planificar con base en la información de progreso actual. Sin embargo, como Postgres soporta consultas en streaming, cambiar el plan a mitad de la ejecución requeriría cambios importantes en la infraestructura.
• Un usuario comenta que usa explain.dalibo.com y www.pgexplain.dev como herramientas de visualización de consultas. Ambas ofrecen resultados de salida similares.
• Se comenta que mejorar el planificador de consultas es una parte importante en una base de datos, pero que normalmente solo se nota cuando no funciona como uno quisiera. También se comparte la experiencia de que el compilador JIT (Just-In-Time) de las versiones recientes de Postgres no parece tener heurísticas de uso lo suficientemente robustas, y que puede volver más lentas las cargas pequeñas, por lo que conviene desactivarlo.
• Hay curiosidad por saber con qué frecuencia los cambios realmente tienen efecto en consultas reales, en particular el cambio de "usar Limit en lugar de DISTINCT cuando sea posible", y si de verdad hay casos donde eso se aplique. También se pregunta si los desarrolladores de Postgres tienen información sobre esto.
• Se menciona que sería útil contar con un "modo estricto" para probar aplicaciones. En este modo, si no existe un índice que pueda mejorar una consulta, se devolvería un error, y se podrían crear los índices necesarios mediante el comando CREATE INDICES FOR <sql>. También se propone un modo de creación automática de índices para desarrollo y uso interactivo.
• Un amigo de un usuario trabaja como DBA de Microsoft para pymes y afirma que no se puede hacer trabajo serio con Postgres. También dice que le sorprendió que Postgres no tuviera planificador de consultas, aunque eso es incorrecto. Se plantea la duda de qué tan creíble es la afirmación de que MSSQL puede manejar trabajos a mayor escala que Postgres.
• Se plantea la duda de por qué Postgres no implementa hints.
• Hay una pregunta sobre por qué una función anunciada por Citus Data apareció en otro sitio y no en postgresql.org, y si se trata de una función de pago o de una extensión de código abierto.
• Se pregunta en qué momento Postgres puede usar un índice para acelerar consultas con IS NOT DISTINCT FROM.
• Un comentario fue reportado y marcado.