VACUUM a nivel de página en PostgreSQL: qué cambia byte a byte

Fuentes: VACUUM at the Page Level

Este artículo explica, con un enfoque práctico y didáctico, cómo opera el comando VACUUM de PostgreSQL a nivel interno sobre las páginas de heap. A diferencia de la poda de páginas (page pruning), que solo actúa en actualizaciones HOT dentro de una misma página, VACUUM es el mecanismo general para reclamar el espacio de tuplas muertas, limpiar entradas de índice, registrar espacio libre en el free space map y mantener el visibility map.

El texto parte de una tabla de demostración con 50 filas e índices, captura el estado inicial de la página (pd_lower, pd_upper, line pointers y cabeceras de tupla) con las extensiones pageinspect, pg_visibility y pg_freespacemap, y luego ejecuta un DELETE que marca 16 filas como muertas. Antes de VACUUM, las tuplas borradas siguen ocupando espacio físico: solo cambia t_xmax, mientras lp_off, lp_len y los flags permanecen inalterados.

A continuación se detallan las tres pasadas de VACUUM: primero, el heap scan con poda, congelado y recolección de TIDs muertos; segundo, la limpieza de índices, que es la fase más costosa porque exige recorrer todas las páginas de cada índice para eliminar entradas que apunten a TIDs muertos; tercero, la limpieza del heap, que por fin libera los line pointers y registra el espacio recuperado en el free space map.

El artículo incluye snapshots antes y después de cada fase para mostrar exactamente qué cambia en la cabecera de página, los line pointers y las tuplas. Está dirigido a desarrolladores y administradores de bases de datos que necesiten entender el funcionamiento interno de VACUUM para optimizar el autovacuum, prevenir el bloat de tablas e índices y diagnosticar problemas de rendimiento en PostgreSQL. Se complementa con otros textos del mismo autor sobre poda, actualizaciones HOT y por qué VACUUM no siempre cumple lo que promete.