Improve autovacuum "queue and progress" howto
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- postgresql, sql
調査の方向性
Start with docs/postgres-howtos/database-administration/maintenance/autovacuum-queue-and-progress.md, then compare its queries with the Cybertec article, the postgres-ai SQL style guide, and how-to-monitor-xmin-horizon.md. Review the existing queue and progress queries first. Done means the listed PostgreSQL-version coverage, diagnostics, guidance, variants, cross-links, and refreshed screenshot are addressed and the queries remain usable across the stated versions.
索引モデルが issue の本文から書いたものです。
説明
Context
The howto at docs/postgres-howtos/database-administration/maintenance/autovacuum-queue-and-progress.md covers autovacuum queue depth and live progress monitoring. A review against the Cybertec autovacuum monitoring article and the postgres-ai SQL style guide surfaced a number of gaps and improvements.
Correctness / coverage
- Add PG 18+
autovacuum_vacuum_max_thresholdto the trigger formula — effective threshold isleast(max_threshold, threshold + scale_factor * reltuples); without it the query overstates urgency on large tables under PG 18 - Handle
autovacuum_vacuum_insert_threshold/autovacuum_vacuum_insert_scale_factor(PG 13+) — insert-mostly tables are invisible to the current query - Fix inverted
autovacuum_enabledlabel —case when autovacuum_enabled then 'DISABLED' else 'enabled' endis backwards - Add anti-wraparound urgency — compute
age(relfrozenxid)vs.autovacuum_freeze_max_ageandmxid_age(relminmxid)vs.autovacuum_multixact_freeze_max_age, surfacewraparound_urgencyand per-table overrides - Add a
trigger_reasoncolumn — {dead_tuples, inserts, freeze, multixact, in_progress} so each queue row says why it qualifies
Query quality
- Replace regex-based reloption parsing with
LATERAL unnest(reloptions) + FILTER— shorter, faster, easier to extend - Compute explicit
vacuum_urgency = n_dead_tup / effective_thresholdratio and order by it, replacing the current boolean in/out-of-queue approach - Make query version-portable — use
current_setting('autovacuum_vacuum_max_threshold', true)with'Infinity'::float8fallback for PG 13–17 - Handle
reltuples = -1(PG 14+ initial value for freshly created tables) — urgency is meaningless in that case - Filter out temp tables / unlogged tables that won't be autovacuumed
- Use
format('%I.%I', nspname, relname)for therelationcolumn instead of string concatenation - Simplify the
full outer join— aleft join+ optional union handles the "another DB" edge case more clearly
Adjacent diagnostics
- Add a
pg_stat_progress_analyzecompanion query (the "natural extension" already mentioned in the page) - Add visibility-map health query via
pg_visibility_map_summary— different signal from dead-tuple count, relevant for index-only scans - Cross-link
last_autoanalyze/n_mod_since_analyzealongsidelast_autovacuum - Surface throttle math next to in-progress rows — effective MB/s ceiling from
[auto]vacuum_cost_limit,[auto]vacuum_cost_delay, page-cost params
Tuning guidance / prose
- Add a concrete worked example of the "load average" analogy (e.g., "10 tables in queue, 3 workers → effective depth of 3.3")
- Explain when per-table overrides are better than bumping
autovacuum_max_workersglobally - Add a "why is this table stuck in the queue?" checklist: long-running transactions, replication slots, prepared transactions, hot-standby feedback, DDL locks, corruption
- Note
vacuum_buffer_usage_limit(PG 16+) when discussing "make workers run faster" - Cross-link
how-to-monitor-xmin-horizon.mdas the natural next step when cleanup is blocked - Add a version-compatibility callout (which columns/settings require which PG version)
- Cite the Cybertec article as further reading
Output / UX
- Refresh the screenshot (
0067_tables_to_be_autovacuumed_2.png) - Provide a compact variant (no progress columns) for the common case when nothing is actively vacuuming
- Provide a
\watch-friendly variant for staring at an in-progress vacuum
References
- Cybertec: Monitor autovacuum – the queries I prefer (Laurenz Albe, 2026)
- postgres-ai SQL style guide
- Related howto:
how-to-monitor-xmin-horizon.md - Original query source: avito-tech/dba-utils vacuum_queue
- 主要言語
- HTML
- スター
- 0
- フォーク
- 1
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
似ている issue
-
Add: RiC Feedオープンcheck:passed feeds:add
難易度 1/5 1時間未満 初心者へのやさしさ 74/100
メンテナーはふだん 9 日以内に返信
-
/api/db-status hardcodes connected: true, so the badge reads "MongoDB Atlas Connected" while running on the file-store fallback対応中かも @Ashishpatra0-0 が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
vicharanashala/fln#774 ·
メンテナーはふだん 2 日以内に返信
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:other issue-rating: 🦞 diamond lobster no-stale P2
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
openclaw/openclaw#168089 · コメント 2 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
dotnet/SqlClient#4823 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
area:core area:runtime type:security
難易度 2/5 半日 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信