Fortschritt laufender Autovacuum-/VACUUM-Vorgänge überwachen
PostgreSQLWartungBefehl
SELECT p.pid,
a.backend_type,
p.datname,
p.relid::regclass AS table_name,
p.phase,
pg_size_pretty(p.heap_blks_total * current_setting('block_size')::bigint) AS table_size,
round(100.0 * p.heap_blks_scanned / NULLIF(p.heap_blks_total, 0), 1) AS scanned_pct,
round(100.0 * p.heap_blks_vacuumed / NULLIF(p.heap_blks_total, 0), 1) AS vacuumed_pct,
p.index_vacuum_count,
now() - a.xact_start AS running_for,
a.wait_event_type || ':' || a.wait_event AS wait,
left(a.query, 80) AS query
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a USING (pid)
ORDER BY running_for DESC;
-- Busy autovacuum workers / upper limit
SELECT count(*) FILTER (WHERE backend_type = 'autovacuum worker') AS av_workers_busy,
current_setting('autovacuum_max_workers') AS av_max_workers
FROM pg_stat_activity;Was es tut
Zeigt für jedes laufende VACUUM (Autovacuum-Worker oder manuell) Tabelle, Phase, gescannten/bereinigten Heap-Anteil in Prozent, Anzahl der Index-Vacuum-Durchläufe und Wait Event; dazu die Anzahl beschäftigter Autovacuum-Worker.
Wann einsetzen
Um abzuschätzen, wann ein VACUUM auf einer großen Tabelle fertig wird, ob alle Autovacuum-Worker beschäftigt sind (Tabellen in der Warteschlange) und ob Vacuum wegen Drosselung wartet.
Vorsicht
index_vacuum_count > 1 bedeutet, dass die Liste toter Tupel nicht in den Speicher passte und Indizes mehrfach gescannt wurden; erhöhe maintenance_work_mem/autovacuum_work_mem (vor PG17 wird dafür höchstens 1GB genutzt). wait = Timeout:VacuumDelay ist kostenbasierte Drosselung (autovacuum_vacuum_cost_delay/cost_limit). Beende kein Autovacuum, dessen Abfragetext 'to prevent wraparound' enthält; es startet sofort neu. VACUUM FULL und CLUSTER erscheinen in pg_stat_progress_cluster, nicht in dieser View.