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.

Execution-Plan on Ivan Luminaria

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

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