Entrenar un modelo de 4B para producir planes de consulta un 81% más rápidos que Postgres

Artículo original ↗ Discusión en Hacker News ↗

Una entrada de blog afirma que un modelo de lenguaje de 4 mil millones de parámetros puede generar planes de consulta de PostgreSQL que se ejecutan alrededor de un 81% más rápido en un benchmark pequeño y en memoria, lo que provoca un debate sobre si los LLMs pertenecen o no a la optimización central de bases de datos. Los comentaristas cuestionan la practicidad de reentrenar modelos, la omisión del tiempo de planificación en las afirmaciones de rendimiento y el riesgo de sobreajuste a cargas de trabajo estrechas, al tiempo que señalan que las heurísticas clásicas basadas en costes y de aprendizaje automático ya tienen dificultades con distribuciones de datos cambiantes. Muchos ven potencial para un uso offline o híbrido —por ejemplo, generar sugerencias para consultas problemáticas— en lugar de reemplazar a planificadores maduros y deterministas en sistemas reales de alto rendimiento.

Corrección y lo que realmente controla el LLM

  • Varios preguntan cómo se sabe que el plan producido por el LLM sigue calculando la consulta correcta.
  • Aclaración: el LLM no reescribe SQL; solo ajusta parámetros/sugerencias del planificador. Postgres sigue verificando la validez del plan y recurre a una alternativa si las sugerencias no corresponden a un plan legal.
  • Algunos proponen comprobación de equivalencia o herramientas de prueba, pero otros señalan que demostrar la equivalencia de forma completa es indecidible o NP-hard en general.

Determinismo, estadísticas y deriva de la carga de trabajo

  • Los planes de consulta no son deterministas; dependen de las estadísticas, los valores de los parámetros y la forma de los datos.
  • Las cargas de trabajo reales suelen ver regresiones bruscas de planes cuando cambian las estadísticas o aparecen patrones raros de cardinalidad.
  • Las sugerencias o los planes aprendidos pueden volverse inválidos cuando las distribuciones de datos o las cargas de trabajo cambian, lo que limita el valor de una optimización offline de “una sola vez y listo”.

Afirmaciones de rendimiento y realismo del benchmark

  • Varios comentaristas cuestionan la mejora del 81%:
    • El conjunto de datos es pequeño (8 GB), cabe en memoria, las consultas están en caliente y son SELECT de solo lectura.
    • Preocupación por el sobreajuste a este entorno y por la falta de evidencia en sistemas OLTP/HTAP grandes y cambiantes.
    • Algunos señalan que parámetros de Postgres mal ajustados (por ejemplo, random_page_cost, índices o estadísticas faltantes) por sí solos pueden explicar grandes diferencias.
  • Otros indican que el proyecto ignora la latencia de planificación; un planificador práctico debe mejorar “planificación + ejecución” bajo restricciones reales.

LLMs frente a otros enfoques

  • Muchos sostienen que el ML clásico o las redes neuronales especializadas serían más apropiadas que un LLM general (heurísticas al estilo AlphaGo, GNNs).
  • Se citan herramientas existentes como la optimización basada en costes, los histogramas de Postgres, GEQO y las heurísticas aprendidas en compiladores como precedentes más específicos.
  • Algunos ven los LLMs como excesivos y difíciles de depurar; otros los consideran prometedores para exploración offline y destilación en modelos más pequeños.

Riesgo operativo y modelos de uso

  • Escepticismo ante la incorporación de un modelo de 4B parámetros en rutas críticas de bases de datos en producción, especialmente con alto QPS.
  • Más entusiasmo por el uso offline o en tiempo de prueba: clonar producción, analizar consultas lentas, generar sugerencias, confirmarlas en control de versiones y verificarlas mediante pruebas.
  • Persisten preocupaciones sobre la no determinación, el riesgo de regresión y la falta de correspondencia de habilidades para equipos de bases de datos que gestionan componentes basados en LLM.

Otros temas

  • Debate sobre la posible aceleración mediante GPU para joins/sorts frente a planificadores más inteligentes.
  • Menciones a planes de consulta adaptativos (cambio de plan en pleno vuelo) como el “resultado final” a largo plazo.
  • Debate paralelo sobre la ética de la destilación y el ecosistema de IA más amplio, además de algunos elogios por la claridad y la calidad visual del texto.