Postgresql 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.

Roles y usuarios en PostgreSQL: por qué todo es (solo) un ROLE

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

La primera vez que trabajé seriamente con PostgreSQL venía de años utilizando otros motores de base de datos. Buscaba el comando CREATE USER. Lo encontraba. Luego veía CREATE ROLE. Luego ALTER USER. Luego ALTER ROLE.
Durante unos minutos pensé: “Vale, aquí alguien se divierte confundiendo a la gente”.

En realidad no. PostgreSQL es mucho más coherente de lo que parece. Solo que lo es a su manera.

En PostgreSQL no existen usuarios. Existen roles. #

La clave es esta: en PostgreSQL todo es un ROLE.

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.