LLM vs POWA: optimizando querys SQL con IA vs herramientas tradicionales

Nuestra base de datos preferida en fintech.works siempre ha sido PostgreSQL, desde el inicio fue capaz de cumplir con todos nuestros requisitos de performance con su robustez característica, pero como los sistemas que desarrollamos son para el área financiera, hay veces que los querys que ejecutamos en las distintas bases de datos pueden ser extremadamente complejas, difíciles de optimizar y capaces de colmar la paciencia de nuestro elefante azul.

Para estos casos nuestra herramienta preferida para analizar querys complejas es POWA.

¿Qué es POWA?

POWA es una extensión de PostgreSQL que actúa como una capa de visualización sobre pg_stat_statements, lo que nos permite:

• Monitorear queries lentas en tiempo casi real.

• Detectar tendencias y regresiones de rendimiento.

• Explorar planes de ejecución con detalles visuales.

• Comparar estadísticas históricas y detectar variaciones.

Requiere instalación, permisos adecuados, y cierto conocimiento técnico para interpretar los resultados. Esto lo hace ideal para DBA o equipos DevOps que monitorean entornos críticos o para casos como el nuestro donde se lo utiliza ya en el proceso de desarrollo para ir optimizando y haciendo troubleshooting durante el desarrollo.

Finalmente POWA incluye una interfaz web que nos permite ver todas las métricas y estadísticas generada por su backend pero con mucho énfasis en mostrar en primer plano querys que tardan mucho y las optimizaciones que se pueden aplicar como por ejemplo índices.

Caso real y prueba con LLM

Durante el troubleshooting de una aplicación legacy que presentaba problemas de performance fuimos navegando hasta llegar a la conclusión que nuestro cuello de botella estaba en la base de datos.

En este punto era obvio que los problemas de performance se debían a querys mal optimizadas por la forma en la que ocurrieron los timeouts en la aplicación sumado al uso de cpu alto justamente cuando la aplicación hacía cierto tipo de consultas.

Con esta información nos fuimos directamente a consultar los querys en POWA, pero hubo un problema, este servidor no tenía instalada la extensión ni la web-ui, y al ser una base de datos productiva no podíamos darnos el lujo de instalar POWA sin antes hacer una ronda de backups y pruebas en una réplica.

Pero lastimosamente no pudimos terminar el proceso de instalación, en pocas palabras la versión de la web-ui powa-web no era compatible con la versión de la extensión instalada en la base de datos (la cual depende de la versión de Postgres) y no podíamos bajar la versión de powa-web ya que no era compatible con python3, por lo que recurrimos a sacar las estadísticas a mano mediante querys a la tabla pg_stat_statements.

Con las querys más costosas identificadas (alrededor de 700 milisegundos), recurrimos a ChatGPT para ver si nos podría dar algunos insights sobre las mismas mientras preparamos una versión actualizada de la base de datos y poder instalar POWA, pero aquí los resultados fueron mejores de los que nos imaginábamos.

Insights de ChatGPT

La query que más tardaba era de este tipo (nombre de tabla y campos cambiados):

SELECT ...
FROM microservicio.log tl1_0
WHERE tl1_0.status = $1
  AND tl1_0.name = $2
  AND tl1_0.created_timestamp <= $3
  AND tl1_0.ff = $5
  AND COALESCE(tl1_0.r_count, $6) < $7
  AND COALESCE(tl1_0.v_count, $8) < $9
  AND COALESCE(tl1_0.pr_count, $10) < $11
ORDER BY tl1_0.created_timestamp
FETCH FIRST $4 ROWS ONLY;

Con 741 milisegundos en promedio era un dolor de cabeza literal para PostgreSQL ya que el uso de CPU subía al 50% durante la ejecución del mismo.

El otro query problemático era algo así:

SELECT tl1_0.handle
FROM microservicio.listentry g1_0, microservicio.log tl1_0
WHERE g1_0.level = $1
  AND g1_0.acct = $2
  AND g1_0.tp = tl1_0.tp_id
ORDER BY tl1_0.created_timestamp DESC
FETCH FIRST $3 ROWS ONLY;

Con 400 milisegundos y ejecuciones en simultáneo era urgente su optimización.

A estos dos querys los pasamos por ChatGPT junto a estos otros valores brindados por pg_stat_statements:

1. calls
2. total_exec_time
3. rows
4. mean_exec_time
5. stddev_exec_time

Aquí los insights brindados por POWA (instalado en un servidor actualizado) y ChatGPT fueron:

POWA

Nos mostró claramente que los tiempos se concentraban en ordenamientos (Sort) y scans secuenciales. Como optimización recomendó índices sobre created_timestamp, pero no consideró columnas combinadas ni el efecto de COALESCE().

En general no tiene forma de recomendar una optimización directa sobre filtros múltiples ni estrategias de reescritura.

ChatGPT

En el caso de ChatGPT quien solo recibió el query junto a sus métricas de pg_stat_statements este pudo analizar el query inmediatamente sin tener que instalar nada e identificó que el ORDER BY + FETCH FIRST podía beneficiarse de un índice compuesto.

También sugirió reescribir la lógica para evitar COALESCE() si los valores pueden tener DEFAULT 0, habilitando el uso de índices simples.

Y de paso nos explicó por qué un índice sobre created_timestamp solo no era suficiente si los filtros no reducían el dataset antes del sort.

Resultados de ambas optimizaciones

Para ambos casos los resultados fueron los siguientes luego de aplicar:

1. La primera consulta bajó de 741 ms a < 50 ms
2. La segunda consulta pasó de 400 ms a < 20 ms

Si bien no hubo diferencias en los índices recomendados por las dos herramientas hay que destacar que en el caso de los LLMs estas vienen acompañadas con mucha información sobre cada query en forma de explicaciones de cada paso, posibles optimizaciones y un resumen final.

Este tipo de resultado (que si bien no tiene la granularidad y exactitud de las herramientas que tienen conexión directa a la base de datos) es excelente teniendo en cuenta que un LLM no necesita ningún tipo de conexión a la base de datos ni configuración previa.

Conclusión: colaboración, no reemplazo

POWA seguirá siendo nuestra herramienta de preferencia para detectar problemas y optimizar querys en ambientes PostgreSQL. Sin embargo ahora sabemos que LLMs como ChatGPT, que si bien no reemplazan el análisis estadístico, ofrecen un valor complementario clave gracias a:

1. Diagnóstico basado en comprensión semántica, o sea que su respuesta se adapta a preguntas como "necesito optimizar", "necesito arreglar" y "quiero aprender".
2. Sugerencias contextualizadas al query particular.
3. Capacidad de generar scripts listos para aplicar.
4. Capacidad de ofrecer insights con solo el query y sus estadísticas.
5. No necesita conexión a la base de datos.

Todas estas ventajas hacen que las LLMs ahora ocupen un lugar en nuestro tool de herramientas para el performance tuning en base de datos. En general, con respecto a las LLMs notamos que a veces, una segunda opinión (humana o no) marca la diferencia.