Performance on Ivan Luminaria

VACUUM y autovacuum: por qué PostgreSQL necesita que alguien limpie

Tue, 24 Mar 2026 08:03:00 +0100

Hace un par de años me pidieron revisar un PostgreSQL en producción que “se ralentiza cada semana”. Siempre el mismo patrón: el lunes va bien, el viernes es un desastre. El fin de semana alguien reinicia el servicio y se empieza de nuevo.

Base de datos de unos 200 GB. Las tablas principales ocupaban casi el triple del espacio efectivo de los datos. Queries cayendo en sequential scan donde no deberían. Tiempos de respuesta que subían día tras día.

Oracle en Linux: los parámetros del kernel que nadie configura

Tue, 24 Feb 2026 08:03:00 +0100

El cliente era una empresa de logística con Oracle 19c Enterprise Edition sobre Oracle Linux 8. Sesenta usuarios concurrentes, un ERP a medida, unos 400 GB de datos. El servidor era un Dell PowerEdge con 128 GB de RAM y 32 cores.

Las quejas eran vagas pero persistentes: “El sistema va lento.” “Las queries de la mañana tardan el doble que hace dos meses.” “De vez en cuando se congela todo unos segundos.”

AWR, ASH y los 10 minutos que salvaron un go-live

Tue, 10 Feb 2026 08:03:00 +0100

Viernes, 18:40. Ya tenía la chaqueta puesta, listo para salir. El teléfono vibra. Es el project manager.

“Ivan, tenemos un problema. El sistema va lentísimo. Mañana por la mañana es el go-live.”

No es la primera vez que recibo una llamada así. Pero el tono era diferente. No era la queja genérica sobre la lentitud. Era pánico.

Me reconecto por VPN, abro una sesión en la base de datos Oracle 19c del cliente. Lo primero que hago es una comprobación rápida:

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é:

Oracle Partitioning: cuando 2 mil millones de filas ya no caben en una query

Tue, 23 Dec 2025 08:03:00 +0100

Dos mil millones de filas. No es un número que se alcance en un día. Se necesitan años de transacciones, movimientos, registros diarios que se acumulan. Y durante todo ese tiempo la base de datos funciona, las consultas responden, los reportes salen. Luego un día alguien abre un ticket: “el reporte mensual tarda cuatro horas.”

Cuatro horas. Para un reporte que seis meses antes tardaba veinte minutos.

No es un bug. No es un problema de red o de almacenamiento lento. Es la física de los datos: cuando una tabla crece más allá de cierto umbral, los enfoques que funcionaban dejan de funcionar. Y si no diseñaste la estructura para manejar ese crecimiento, la base de datos hace lo único que puede: leerlo todo.

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.