pg_stat_progress_vacuum

PostgreSQL documentation ↗Source definition ↗

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.

First seen PG 9.6Last seen PG 19Columns 15

9.0 9.1 9.2 9.3 9.4 9.5 9.6 10 11 12 13 14 15 16 17 18 19^β3

Checked column by column against a PostgreSQL 18.6 instance · Raw measurement record ↗

Columns PostgreSQL 18

pg_stat_progress_vacuum

COLUMN	TYPE	DESCRIPTION
`pid`	`integer`	Process ID of backend.
`datid`	`oid`	OID of the database to which this backend is connected.
`datname`	`name`	Name of the database to which this backend is connected.
`relid`	`oid`	OID of the table being vacuumed.
`phase`	`text`	Current processing phase of vacuum. See Table 27.46.
`heap_blks_total`	`bigint`	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`	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`	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`	Number of completed index vacuum cycles.
`max_dead_tuple_bytes`	`bigint`	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`	Amount of dead tuple data collected since the last index vacuum cycle.
`num_dead_item_ids`	`bigint`	Number of dead item identifiers collected since the last index vacuum cycle.
`indexes_total`	`bigint`	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`	Number of indexes processed. This counter only advances when the phase is vacuuming indexes or cleaning up indexes.
`delay_time`	`double precision`	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.

Columns marked "implicit" are not included in SELECT *; some early statistics views are completed from same-version source, and the extra provenance is shown in the column description.

Column evolution matrix

Hover a cell for the column type

PresentAdded / type or attribute changeRemoved

COLUMN	9.0	9.1	9.2	9.3	9.4	9.5	9.6	10	11	12	13	14	15	16	17	18	19
`pid`	–	–	–	–	–	–
`datid`	–	–	–	–	–	–
`datname`	–	–	–	–	–	–
`relid`	–	–	–	–	–	–
`phase`	–	–	–	–	–	–
`heap_blks_total`	–	–	–	–	–	–
`heap_blks_scanned`	–	–	–	–	–	–
`heap_blks_vacuumed`	–	–	–	–	–	–
`index_vacuum_count`	–	–	–	–	–	–
`max_dead_tuples`	–	–	–	–	–	–									−	–	–
`num_dead_tuples`	–	–	–	–	–	–									−	–	–
`max_dead_tuple_bytes`	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`dead_tuple_bytes`	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`num_dead_item_ids`	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`indexes_total`	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`indexes_processed`	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`delay_time`	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`mode`	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–
`started_by`	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–

9.0 is the coverage baseline; a column already present in the baseline is not marked as added. The matrix aligns columns by name, so a rename appears as the old column removed and a new column added.

Evolution timeline

Changes between adjacent majors

PostgreSQL 19 ← 18

+ mode+ started_by1 column description updates

PostgreSQL 18 ← 17

+ delay_time

PostgreSQL 17 ← 16

+ max_dead_tuple_bytes+ dead_tuple_bytes+ num_dead_item_ids+ indexes_total+ indexes_processed− max_dead_tuples− num_dead_tuples1 column description updatesCatalog description updated

PostgreSQL 16 ← 15

1 column description updatesCatalog description updated

PostgreSQL 15 ← 14

1 column description updates

PostgreSQL 14 ← 13

1 column description updatesCatalog description updated

PostgreSQL 13 ← 12

1 column description updatesCatalog description updated

PostgreSQL 12 ← 11

1 column description updatesCatalog description updated

PostgreSQL 10 ← 9.6

1 column description updates

PostgreSQL 9.6 ← 9.5Catalog added

+ pid+ datid+ datname+ relid+ phase+ heap_blks_total+ heap_blks_scanned+ heap_blks_vacuumed+ index_vacuum_count+ max_dead_tuples+ num_dead_tuples

Compare any two versions

FROMTOInclude description updates

Pick two versions to see added, removed, and retyped columns. The interactive comparison needs JavaScript; the evolution timeline reads fine without it.