Una base de datos PostgreSQL de 200 GB con tablas infladas al triple de su tamaño real. El autovacuum estaba activo, pero mal configurado. Cómo diagnosticar el bloat, leer pg_stat_user_tables y hacer tuning sin desactivar nada.
Un cliente con Oracle 19c en Linux y rendimiento decepcionante. Instalación por defecto, sin tuning. Huge Pages, semáforos, I/O scheduler, THP y límites de seguridad: todo lo que faltaba — con los números del antes y después.
Viernes por la noche, víspera de un go-live. El rendimiento se desploma. Con AWR y ASH encontré un full table scan oculto en un procedimiento almacenado en menos de diez minutos — y el paso a producción siguió adelante.
A real-world PostgreSQL performance case where a LIKE '%value%' caused a full scan and degraded response times. Analysis, execution plan, and a scalable indexing strategy.
Un cliente con una tabla de transacciones de 2 mil millones de filas y consultas de reportes que habían pasado de segundos a horas. Cómo lo resolví con partitioning Oracle — range, interval, partition pruning e índices locales.
Un caso real donde el optimizer eligio un nested loop sobre 2 millones de filas porque las estadisticas estaban desactualizadas. Como leer un plan de ejecucion, encontrar las senales de alarma y actuar.