pg_stat_progress_vacuum
Whenever VACUUM is running, the pg_stat_progress_vacuum view will contain one row for each backend (including autovacuum worker processes) that is currently vacuuming. The tables below describe the information that will be reported and provide information about how to interpret it. Progress for VACUUM FULL commands is reported via pg_stat_progress_cluster because both VACUUM FULL and CLUSTER rewrite the table, while regular VACUUM only modifies it in place. See Section 27.4.2.
English manual coverage begins with PostgreSQL 7.4. Source history and runtime observations have their own recorded version boundaries.
Reading PG 18·Select a recorded version
- kind
- progress
- lang
- en
- measured attributes
- true
- metadata release
- 18.6
- runtime columns
- pid, datid, datname, relid, phase, heap_blks_total, heap_blks_scanned, heap_blks_vacuumed, index_vacuum_count, max_dead_tuple_bytes, dead_tuple_bytes, num_dead_item_ids, indexes_total, indexes_processed, delay_time
- runtime verified
- false
- source
- english-manual
Definition PG 18
Whenever VACUUM is running, the pg_stat_progress_vacuum view will contain one row for each backend (including autovacuum worker processes) that is currently vacuuming. The tables below describe the information that will be reported and provide information about how to interpret it. Progress for VACUUM FULL commands is reported via pg_stat_progress_cluster because both VACUUM FULL and CLUSTER rewrite the table, while regular VACUUM only modifies it in place. See Section 27.4.2.
Catalog columns
| Column | Type | Nullability | Description |
|---|---|---|---|
| pid | integer | Nullable | Process ID of backend. |
| datid | oid | Nullable | OID of the database to which this backend is connected. |
| datname | name | Nullable | Name of the database to which this backend is connected. |
| relid | oid | Nullable | OID of the table being vacuumed. |
| phase | text | Nullable | Current processing phase of vacuum. See Table 27.46. |
| heap_blks_total | bigint | Nullable | Total number of heap blocks in the table. This number is reported as of the beginning of the scan; blocks added later will not be (and need not be) visited by this VACUUM. |
| heap_blks_scanned | bigint | Nullable | Number of heap blocks scanned. Because the visibility map is used to optimize scans, some blocks will be skipped without inspection; skipped blocks are included in this total, so that this number will eventually become equal to heap_blks_total when the vacuum is complete. This counter only advances when the phase is scanning heap. |
| heap_blks_vacuumed | bigint | Nullable | Number of heap blocks vacuumed. Unless the table has no indexes, this counter only advances when the phase is vacuuming heap. Blocks that contain no dead tuples are skipped, so the counter may sometimes skip forward in large increments. |
| index_vacuum_count | bigint | Nullable | Number of completed index vacuum cycles. |
| max_dead_tuple_bytes | bigint | Nullable | Amount of dead tuple data that we can store before needing to perform an index vacuum cycle, based on maintenance_work_mem. |
| dead_tuple_bytes | bigint | Nullable | Amount of dead tuple data collected since the last index vacuum cycle. |
| num_dead_item_ids | bigint | Nullable | Number of dead item identifiers collected since the last index vacuum cycle. |
| indexes_total | bigint | Nullable | Total number of indexes that will be vacuumed or cleaned up. This number is reported at the beginning of the vacuuming indexes phase or the cleaning up indexes phase. |
| indexes_processed | bigint | Nullable | Number of indexes processed. This counter only advances when the phase is vacuuming indexes or cleaning up indexes. |
| delay_time | double precision | Nullable | Total time spent sleeping due to cost-based delay (see Section 19.10.2), in milliseconds (if track_cost_delay_timing is enabled, otherwise zero). This includes the time that any associated parallel workers have slept. However, parallel workers report their sleep time no more frequently than once per second, so the reported value may be slightly stale. |
Compare versions
Complete source facts
documentation revision
{"inputs":[{"file":"progress-reporting.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"4a6cdd8228f2d858318f2056687ac4e2467e2c58e5fed10bdb583ba8eb66fec5","version":"18.7"},{"file":"progress-reporting.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"0ab33caa1959f857312f1a866b2b0f0afde18c3fd85db5d957eefa1b7a2e441f","version":"18.7"}],"release":"18.7","runtime_remeasured":false,"source_revision":"pgdoc:b9f0e7232f60f380d642ac9b99226606c254b552"}Source references
Full definition and evidence JSON
Definition sources
center · PostgreSQL 18 · catalog-bilingual-repair:f3752c354908a62c93dba6b721ff358f7c63dd6a0581899a7d6e3dfcc2c373d7
Text language: en · catalog-bilingual-repair:f3752c354908a62c93dba6b721ff358f7c63dd6a0581899a7d6e3dfcc2c373d7