Tame the growth of your database
summary
Explains PostgreSQL’s MVCC copy‑on‑write, how HOT updates avoid index write amplification, and how easy app patterns undo that. Uses pageinspect and pg_stat_user_tables to show a 12 KB live table swelling to 20 GB because autovacuum budget and a competing long vacuum block reclamation. Demonstrates the Django ORM calling save that updates every field (causing repeated row copies), a partial index on updated_at preventing HOT updates, and index bloat rising (primary‑key entries growing from 1 to 3, four updates observed).
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:10Multiversion concurrency control
- 3:39What is bloat
- 5:45Vacuum basics
- 9:41Vacuum full explained
- 10:25Autovacuum importance
- 12:13Tuning vacuum frequency
- 14:21Write amplification
- 15:04Hot updates
- 21:36Preventing bloat
- 22:19Django example
- 24:09Oracle patterns
- 26:39Demos start
- 36:24Django demo
- 45:05Summary and Q&A
related talks
48mInside Postgres: why VACUUM matters
25mUnderstanding & Managing Postgres Table Bloat
27mMaintaining Large Tables in PostgreSQL
49mA Detailed Understanding of MVCC and Autovacuum Internals in PostgreSQL 14
50mWe have multiple concurrent versions of this title trying to understand MVCC
55mUnderstanding Autovacuum
39mDeep dive into PostgreSQL internal statistics
50mSolving PostgreSQL Wicked Problems