Bloat and vacuum
Dead row versions left by MVCC occupy space until a background process reclaims them; if it falls behind, tables and indexes grow without the data growing.
Bloat is not a bug but a maintenance obligation. The failure mode is gradual: queries slow as the planner reads more pages for the same rows, and the cause is invisible in the query itself.
Explained in depth
PostgreSQL internals that decide production behaviour - MVCC and XID wraparound, autovacuum thresholds, work_mem, WAL durability, indexes, replication.
PostgreSQL REPACK - reclaiming space without the lockHow PostgreSQL reclaims dead-tuple space by rewriting a table - the pg_repack extension's trigger-and-log-table mechanism that carried PG 15-18, and the native REPACK command landing in PG 19 that replaces the trigger with logical decoding.
PostgreSQL 19 autovacuum - parallel workers and the scoring systemWhat PostgreSQL 19 changes in autovacuum - parallel index vacuuming controlled by autovacuum_max_parallel_workers, a five-component scoring system that decides which tables get vacuumed first, and the new monitoring surface around it.
Implemented by
Learn it in context
Learning path · beginner
PostgreSQL 19 - what changes and what breaksLearning path · intermediate
PostgreSQL REPACK - reclaiming space without the lockLearning path · intermediate
PostgreSQL 19 autovacuum - parallel workers and the scoring systemLearning path · intermediate
PostgreSQL 19 maintenance extensions - pg_visibility, pg_surgery, pg_prewarm, pgrowlocksLearning path · advanced