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 analyzed.
| |phase text
Current processing phase. See Table 27.33.
| |sample\_blks\_total bigint
Total number of heap blocks that will be sampled.
| |sample\_blks\_scanned bigint
Number of heap blocks scanned.
| |ext\_stats\_total bigint
Number of extended statistics.
| |ext\_stats\_computed bigint
Number of extended statistics computed. This counter only advances when the phase is computing extended statistics.
child\_tables\_total bigint
Number of child tables.
| |child\_tables\_done bigint
Number of child tables scanned. This counter only advances when the phase is acquiring inherited sample rows.
current\_child\_table\_relid oid
OID of the child table currently being scanned. This field is only valid when the phase is acquiring inherited sample rows.
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 on which the index is being created.
| |index\_relid oid
OID of the index being created or reindexed. During a non-concurrent CREATE INDEX, this is 0.
command text
The command that is running: CREATE INDEX, CREATE INDEX CONCURRENTLY, REINDEX, or REINDEX CONCURRENTLY.
phase text
Current processing phase of index creation. See Table 27.35.
| |lockers\_total bigint
Total number of lockers to wait for, when applicable.
| |lockers\_done bigint
Number of lockers already waited for.
| |current\_locker\_pid bigint
Process ID of the locker currently being waited for.
| |blocks\_total bigint
Total number of blocks to be processed in the current phase.
| |blocks\_done bigint
Number of blocks already processed in the current phase.
| |tuples\_total bigint
Total number of tuples to be processed in the current phase.
| |tuples\_done bigint
Number of tuples already processed in the current phase.
| |partitions\_total bigint
When creating an index on a partitioned table, this column is set to the total number of partitions on which the index is to be created.
| |partitions\_done bigint
When creating an index on a partitioned table, this column is set to the number of partitions on which the index has been completed.
| #### **Table 27.35. CREATE INDEX Phases** | Phase | Description | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `initializing` | `CREATE INDEX` or `REINDEX` is preparing to create the index. This phase is expected to be very brief. | | `waiting for writers before build` | `CREATE INDEX CONCURRENTLY` or `REINDEX CONCURRENTLY` is waiting for transactions with write locks that can potentially see the table to finish. This phase is skipped when not in concurrent mode. Columns `lockers_total`, `lockers_done` and `current_locker_pid` contain the progress information for this phase. | | `building index` | The index is being built by the access method-specific code. In this phase, access methods that support progress reporting fill in their own progress data, and the subphase is indicated in this column. Typically, `blocks_total` and `blocks_done` will contain progress data, as well as potentially `tuples_total` and `tuples_done`. | | `waiting for writers before validation` | `CREATE INDEX CONCURRENTLY` or `REINDEX CONCURRENTLY` is waiting for transactions with write locks that can potentially write into the table to finish. This phase is skipped when not in concurrent mode. Columns `lockers_total`, `lockers_done` and `current_locker_pid` contain the progress information for this phase. | | `index validation: scanning index` | `CREATE INDEX CONCURRENTLY` is scanning the index searching for tuples that need to be validated. This phase is skipped when not in concurrent mode. Columns `blocks_total` (set to the total size of the index) and `blocks_done` contain the progress information for this phase. | | `index validation: sorting tuples` | `CREATE INDEX CONCURRENTLY` is sorting the output of the index scanning phase. | | `index validation: scanning table` | `CREATE INDEX CONCURRENTLY` is scanning the table to validate the index tuples collected in the previous two phases. This phase is skipped when not in concurrent mode. Columns `blocks_total` (set to the total size of the table) and `blocks_done` contain the progress information for this phase. | | `waiting for old snapshots` | `CREATE INDEX CONCURRENTLY` or `REINDEX CONCURRENTLY` is waiting for transactions that can potentially see the table to release their snapshots. This phase is skipped when not in concurrent mode. Columns `lockers_total`, `lockers_done` and `current_locker_pid` contain the progress information for this phase. | | `waiting for readers before marking dead` | `REINDEX CONCURRENTLY` is waiting for transactions with read locks on the table to finish, before marking the old index dead. This phase is skipped when not in concurrent mode. Columns `lockers_total`, `lockers_done` and `current_locker_pid` contain the progress information for this phase. | | `waiting for readers before dropping` | `REINDEX CONCURRENTLY` is waiting for transactions with read locks on the table to finish, before dropping the old index. This phase is skipped when not in concurrent mode. Columns `lockers_total`, `lockers_done` and `current_locker_pid` contain the progress information for this phase. | ## 27.4.3. VACUUM Progress Reporting 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.4](https://www.postgresql.org/docs/current/progress-reporting.html#CLUSTER-PROGRESS-REPORTING). #### **Table 27.36. `pg_stat_progress_vacuum` View** |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.37.
| |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\_tuples bigint
Number of dead tuples that we can store before needing to perform an index vacuum cycle, based on maintenance\_work\_mem.
| |num\_dead\_tuples bigint
Number of dead tuples collected since the last index vacuum cycle.
| #### **Table 27.37. VACUUM Phases** | Phase | Description | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `initializing` | `VACUUM` is preparing to begin scanning the heap. This phase is expected to be very brief. | | `scanning heap` | `VACUUM` is currently scanning the heap. It will prune and defragment each page if required, and possibly perform freezing activity. The `heap_blks_scanned` column can be used to monitor the progress of the scan. | | `vacuuming indexes` | `VACUUM` is currently vacuuming the indexes. If a table has any indexes, this will happen at least once per vacuum, after the heap has been completely scanned. It may happen multiple times per vacuum if [maintenance\_work\_mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) is insufficient to store the number of dead tuples found. | | `vacuuming heap` | `VACUUM` is currently vacuuming the heap. Vacuuming the heap is distinct from scanning the heap, and occurs after each instance of vacuuming indexes. If `heap_blks_scanned` is less than `heap_blks_total`, the system will return to scanning the heap after this phase is completed; otherwise, it will begin cleaning up indexes after this phase is completed. | | `cleaning up indexes` | `VACUUM` is currently cleaning up indexes. This occurs after the heap has been completely scanned and all vacuuming of the indexes and the heap has been completed. | | `truncating heap` | `VACUUM` is currently truncating the heap so as to return empty pages at the end of the relation to the operating system. This occurs after cleaning up indexes. | | `performing final cleanup` | `VACUUM` is performing final cleanup. During this phase, `VACUUM` will vacuum the free space map, update statistics in `pg_class`, and report statistics to the statistics collector. When this phase is completed, `VACUUM` will end. | ## 27.4.4. CLUSTER Progress Reporting Whenever `CLUSTER` or `VACUUM FULL` is running, the `pg_stat_progress_cluster` view will contain a row for each backend that is currently running either command. The tables below describe the information that will be reported and provide information about how to interpret it. #### **Table 27.38. `pg_stat_progress_cluster` View** |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 clustered.
| |command text
The command that is running. Either CLUSTER or VACUUM FULL.
phase text
Current processing phase. See Table 27.39.
| |cluster\_index\_relid oid
If the table is being scanned using an index, this is the OID of the index being used; otherwise, it is zero.
| |heap\_tuples\_scanned bigint
Number of heap tuples scanned. This counter only advances when the phase is seq scanning heap, index scanning heap or writing new heap.
heap\_tuples\_written bigint
Number of heap tuples written. This counter only advances when the phase is seq scanning heap, index scanning heap or writing new heap.
heap\_blks\_total bigint
Total number of heap blocks in the table. This number is reported as of the beginning of seq scanning heap.
heap\_blks\_scanned bigint
Number of heap blocks scanned. This counter only advances when the phase is seq scanning heap.
index\_rebuild\_count bigint
Number of indexes rebuilt. This counter only advances when the phase is rebuilding index.
Column Type
Description
| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |pid integer
Process ID of a WAL sender process.
| |phase text
Current processing phase. See Table 27.41.
| |backup\_total bigint
Total amount of data that will be streamed. This is estimated and reported as of the beginning of streaming database files phase. Note that this is only an approximation since the database may change during streaming database files phase and WAL log may be included in the backup later. This is always the same value as backup\_streamed once the amount of data streamed exceeds the estimated total size. If the estimation is disabled in pg\_basebackup (i.e., --no-estimate-size option is specified), this is NULL.
backup\_streamed bigint
Amount of data streamed. This counter only advances when the phase is streaming database files or transferring wal files.
tablespaces\_total bigint
Total number of tablespaces that will be streamed.
| |tablespaces\_streamed bigint
Number of tablespaces streamed. This counter only advances when the phase is streaming database files.