Pg_hint_plan: Forzar a PostgreSQL a ejecutar los planes de consulta como tú quieres

Qué proporciona pg_hint_plan

• La extensión permite a los usuarios sesgar el planificador de PostgreSQL hacia planes específicos (joins, índices, etc.) sin cambiar el PostgreSQL central.
• Se considera especialmente valiosa para:
  • Incidentes de producción de emergencia cuando el planificador elige un plan desastroso.
  • Investigación/experimentación cuando quieres fijar algunas elecciones de plan y dejar que el planificador gestione el resto.
  • Migrar desde otras bases de datos (por ejemplo, mediante Babelfish) donde las cargas de trabajo existentes dependen de hints.

Problemas prácticos al usarlo

• La interfaz de tabla de hints se describe como frágil:
  • La coincidencia es sensible a los espacios en blanco y puede fallar en silencio.
  • El manejo de parámetros es incómodo; las herramientas anteriores dificultaban iterar sobre consultas parametrizadas, aunque las versiones más nuevas de psql ayudan.
• La extensión cambia los costes del plan para “sugerir con fuerza” un plan; si un plan con hints es imposible, PostgreSQL aún elige otra cosa.

Debate: ¿Son buenos o malos los hints?

• Preocupaciones:
  • Los hints pueden congelar planes subóptimos a medida que evolucionan los datos y las versiones de PostgreSQL.
  • Los desarrolladores rara vez revisan de nuevo las consultas con hints; se acumula la basura.
  • Postura del desarrollo central (tal como se describe): mejor mejorar las estadísticas y el optimizador, no añadir hints al SQL.
• Contraargumentos:
  • En producción, a menudo se valora más la previsibilidad que la optimalidad teórica; evitar regresiones repentinas del plan es crítico.
  • Las estadísticas y la configuración del planificador son complejas, globales y arriesgadas; los hints son localizados y más fáciles de razonar para una sola consulta.
  • Las estadísticas y el optimizador de PostgreSQL tienen debilidades conocidas a gran escala y con datos correlacionados o sesgados; algunos problemas han permanecido sin resolver durante años.
  • Los hints se describen como “assembly en línea”: malos como valor predeterminado, invaluables para casos límite poco frecuentes.

Alternativas y enfoques de ajuste

• Remedios sugeridos sin hints:
  • VACUUM ANALYZE, autovacuum ajustado.
  • Aumentar los objetivos de estadísticas por columna o usar estadísticas extendidas/personalizadas.
  • Ajustes de configuración del planificador (join_collapse_limit, parámetros de coste) acotados con SET LOCAL.
  • Cambios de esquema/índices (índices compuestos o parciales) para dar mejor soporte a consultas frecuentes.

Puntos de dolor del planificador y ejemplos

• Múltiples informes de consultas con LIMIT + ORDER BY + WHERE que eligen planes muy pobres, especialmente con columnas correlacionadas o sesgadas.
• Desacuerdo sobre con qué frecuencia ocurren cambios catastróficos de plan, pero hay consenso en que sí ocurren, particularmente en tablas muy grandes.
• Algunos sostienen que esto hace que PostgreSQL sea “peligroso” en producción sin una forma fiable de fijar u sobrescribir planes.