https://www.postgresscripts.com/tags/dead-tuples/Recent content in Dead Tuples on Postgres ScriptsHugo -- gohugo.ioenPostgresScripts.comSun, 12 Jul 2026 00:00:00 +0000https://www.postgresscripts.com/post/postgresql-last-vacuum-standalone/Sun, 12 Jul 2026 00:00:00 +0000https://www.postgresscripts.com/post/postgresql-last-vacuum-standalone/ <h2 id="monitor-last-vacuum-runs-with-pg_stat_user_tables">Monitor Last VACUUM Runs with pg_stat_user_tables</h2> <p>A table's dead tuple count climbing while <code>last_autovacuum</code> stays weeks old isn't noise — it's the clearest sign autovacuum is falling behind, and <a href="https://www.postgresql.org/docs/current/monitoring-stats.html">pg_stat_user_tables</a> is where that gap becomes visible in a single query, without tailing logs or guessing at a schedule.</p> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1012089347386563" crossorigin="anonymous"></script> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-1012089347386563" data-ad-slot="7945792173" data-ad-format="auto" data-full-width-responsive="true"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> <h2 id="purpose-and-overview">Purpose and Overview</h2> <p><code>pg_stat_user_tables</code> is a cumulative statistics view: one row per user table, holding scan counts, tuple counts, and maintenance timestamps that accumulate for the life of the server (or since the last <code>pg_stat_reset()</code>). The view carries columns for two distinct maintenance operations in the same row — VACUUM and ANALYZE — but they trigger independently, run on different thresholds, and carry different operational risk. Conflating them in a single audit muddies the signal.</p>