El resultado principal: un modelo de 4 mil millones de parámetros fue entrenado para producir planes de ejecución de consultas que superaron al planificador integrado de Postgres en 81% de tiempo de ejecución. Esto es notable porque la planificación de consultas es una de las partes más maduras y ajustadas manualmente de una base de datos moderna — superarla no debería ser fácil, especialmente con un modelo lo suficientemente pequeño para ejecutarse en hardware modesto.
Primero, entendamos por qué el planificador es importante. Cuando envías SQL a Postgres, el motor no simplemente lo ejecuta de forma literal. Estima costos, evalúa órdenes de unión, decide entre búsquedas de índice y búsquedas secuenciales, y elige un plan que cree será más económico. Esas estimaciones se basan en estadísticas que frecuentemente están desactualizadas o son incorrectas, y el modelo de costo del planificador es una heurística. Cuando adivina mal, una consulta que debería tomar milisegundos puede tomar minutos. Aquí es donde el modelo demuestra su valor: en lugar de confiar en heurísticas fijas, aprende de los resultados reales de ejecución qué planes realmente se ejecutan rápido.
El enfoque de entrenamiento es aprendizaje por refuerzo: el modelo propone planes, esos planes se ejecutan, y los tiempos de ejecución medidos realmente se convierten en la señal de recompensa. A través de muchas iteraciones, aprende a favorecer formas de plan que funcionan bien en la carga de trabajo objetivo — no solo las que se ven económicas en el papel. Esa es la distinción clave. Postgres optimiza contra un costo estimado; este sistema optimiza contra la latencia real, que es lo que realmente te importa.
La advertencia práctica es que estas ganancias son específicas de la carga de trabajo. Un modelo ajustado en un esquema y mezcla de consultas particular no es un reemplazo directo para un planificador de propósito general, y 81% más rápido en un conjunto de pruebas no garantiza lo mismo en tu tráfico de producción. Considéralo como una técnica de especialización, no como una mejora universal.
¿Qué puedes hacer hoy? Si ejecutas consultas repetidas y de alto valor donde el planificador constantemente hace malas elecciones, el concepto es directamente aplicable: captura tus patrones de consulta reales y sus tiempos de ejecución, y usa esos datos para guiar la selección de planes — ya sea a través de este tipo de enfoque aprendido, sugerencias del planificador o fijación manual de planes. Incluso sin entrenar un modelo, la lección más profunda se mantiene: mide tiempos de ejecución reales, no confíes únicamente en estimaciones de costo, y trata tus consultas recurrentes más lentas como un objetivo de optimización que vale la pena instrumentar.
La señal más amplia es que modelos pequeños y económicos de ejecutar pueden superar significativamente heurísticas de décadas en dominios estrechos y bien definidos — siempre que les proporciones bucles de retroalimentación real. La planificación de consultas es un ejemplo; el mismo patrón se aplica en cualquier lugar donde un sistema toma decisiones basadas en estimaciones imperfectas y puedes medir el resultado real.