Query-Tuning on Ivan Luminaria

When a LIKE '%value%' Slows Everything Down: A Real PostgreSQL Optimization Case

Tue, 06 Jan 2026 08:03:00 +0100

Hace algunas semanas, un cliente me contactó con un problema muy común:

“La búsqueda en la consola administrativa es lenta. A veces tarda varios segundos. Ya hemos reducido las JOIN, pero el problema no ha desaparecido.”

Entorno: PostgreSQL en cloud managed.
Tabla principal: payment_report (~6 millones de filas, 3 GB).
Columna buscada: reference_code.

Query problemática:

SELECT *
FROM reporting.payment_report r
JOIN reporting.payment_cart c ON c.id = r.cart_id
WHERE c.service_id = 1001
 AND r.reference_code LIKE '%ABC123%'
ORDER BY c.created_at DESC
LIMIT 100;

🧠 Primera observación: las JOIN no eran el problema #

Comparé:

EXPLAIN ANALYZE no basta: como leer realmente un plan de ejecucion PostgreSQL

Tue, 28 Oct 2025 08:03:00 +0100

El otro dia un colega me manda una captura de pantalla por Teams. Una query corriendo sobre una tabla de 2 millones de filas, 45 segundos de ejecucion. Me escribe:

“Hice EXPLAIN ANALYZE, pero no entiendo que esta mal. El plan parece correcto.”

Spoiler: el plan no era correcto en absoluto. El optimizer habia elegido un nested loop join donde hacia falta un hash join , y la razon era trivial — estadisticas desactualizadas. Pero para llegar a eso tuve que leer el plan linea por linea, y ahi me di cuenta de que la mayoria de los DBA que conozco usan EXPLAIN ANALYZE como un oraculo binario: si el tiempo es alto, la query es lenta. Fin del analisis.