---
title: "Progress Reporting"
id: progress-reporting
pg_version: "20devel"
---

<a id="progress-reporting"></a>

## 27.4. Progress Reporting

PostgreSQL has the ability to report the progress of certain commands during command execution. Currently, the only commands which support progress reporting are `ANALYZE`, `COPY`, `CREATE INDEX`, `REPACK` (and its obsolete spelling `CLUSTER`), `VACUUM`, [`BASE_BACKUP` [ ( `option` [, ...] ) ]](protocol-replication.md#protocol-replication-base-backup) (i.e., replication command that [pg_basebackup](app-pgbasebackup.md) issues to take a base backup), and online data checksum operations. This may be expanded in the future. 

<a id="analyze-progress-reporting"></a>

### 27.4.1. ANALYZE Progress Reporting

Whenever `ANALYZE` is running, the pg_stat_progress_analyze view will contain a row for each backend that is currently running that command. The tables below describe the information that will be reported and provide information about how to interpret it. 

<a id="pg-stat-progress-analyze-view"></a>

**pg_stat_progress_analyze 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 analyzed. |
| `phase` `text` | Current processing phase. See [Table 27.43](progress-reporting.md#analyze-phases). |
| `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`. |
| `delay_time` `double precision` | Total time spent sleeping due to cost-based delay (see [Section 19.10.2](runtime-config-vacuum.md#runtime-config-resource-vacuum-cost)), in milliseconds (if [`track_cost_delay_timing` (`boolean`)](runtime-config-statistics.md#guc-track-cost-delay-timing) is enabled, otherwise zero). |
| `started_by` `text` | Shows what caused the current `ANALYZE` operation to be started. Possible values are: - `manual`: The analyze was started by an explicit `ANALYZE`, or by `VACUUM` with the `ANALYZE` option. - `autovacuum`: The analyze was started by an autovacuum worker. |

<a id="analyze-phases"></a>

**ANALYZE Phases**

| Phase | Description | 
| --- | --- |
| `initializing` | The command is preparing to begin scanning the heap. This phase is expected to be very brief. | 
| `acquiring sample rows` | The command is currently scanning the table given by `relid` to obtain sample rows. | 
| `acquiring inherited sample rows` | The command is currently scanning child tables to obtain sample rows. Columns `child_tables_total`, `child_tables_done`, and `current_child_table_relid` contain the progress information for this phase. | 
| `computing statistics` | The command is computing statistics from the sample rows obtained during the table scan. | 
| `computing extended statistics` | The command is computing extended statistics from the sample rows obtained during the table scan. | 
| `finalizing analyze` | The command is updating pg_class. When this phase is completed, `ANALYZE` will end. | 


> [!NOTE]
> Note that when `ANALYZE` is run on a partitioned table without the `ONLY` keyword, all of its partitions are also recursively analyzed. In that case, `ANALYZE` progress is reported first for the parent table, whereby its inheritance statistics are collected, followed by that for each partition.

<a id="cluster-progress-reporting"></a>

### 27.4.2. CLUSTER Progress Reporting

Whenever `REPACK`, `CLUSTER` or `VACUUM FULL` is running, the backwards-compatibility 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. 

<a id="pg-stat-progress-cluster-view"></a>

**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`. Because this view exists for backwards-compatibility purposes only, it will translate any `REPACK` command into one of these other two. |
| `phase` `text` | Current processing phase. See [Table 27.45](progress-reporting.md#cluster-phases). |
| `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`. |

<a id="cluster-phases"></a>

**CLUSTER and VACUUM FULL Phases**

| Phase | Description | 
| --- | --- |
| `initializing` | The command is preparing to begin scanning the heap. This phase is expected to be very brief. | 
| `seq scanning heap` | The command is currently scanning the table using a sequential scan. | 
| `index scanning heap` | `CLUSTER` is currently scanning the table using an index scan. | 
| `sorting tuples` | `CLUSTER` is currently sorting tuples. | 
| `writing new heap` | `CLUSTER` is currently writing the new heap. | 
| `swapping relation files` | The command is currently swapping newly-built files into place. | 
| `rebuilding index` | The command is currently rebuilding an index. | 
| `performing final cleanup` | The command is performing final cleanup. When this phase is completed, `CLUSTER` or `VACUUM FULL` will end. | 

<a id="copy-progress-reporting"></a>

### 27.4.3. COPY Progress Reporting

Whenever `COPY` is running, the pg_stat_progress_copy view will contain one row for each backend that is currently running a `COPY` command. The table below describes the information that will be reported and provides information about how to interpret it. 

<a id="pg-stat-progress-copy-view"></a>

**pg_stat_progress_copy 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 on which the `COPY` command is executed. It is set to `0` if copying from a `SELECT` query. |
| `command` `text` | The command that is running: `COPY FROM`, or `COPY TO`. |
| `type` `text` | The I/O type that the data is read from or written to: `FILE`, `PROGRAM`, `PIPE` (for `COPY FROM STDIN` and `COPY TO STDOUT`), or `CALLBACK` (used for example during the initial table synchronization in logical replication). |
| `bytes_processed` `bigint` | Number of bytes already processed by `COPY` command. |
| `bytes_total` `bigint` | Size of source file for `COPY FROM` command in bytes. It is set to `0` if not available. |
| `tuples_processed` `bigint` | Number of tuples already processed by `COPY` command. |
| `tuples_excluded` `bigint` | Number of tuples not processed because they were excluded by the `WHERE` clause of the `COPY` command. |
| `tuples_skipped` `bigint` | Number of tuples skipped because they contain malformed data. This counter only advances when `ignore` is specified to the `ON_ERROR` option. |

<a id="create-index-progress-reporting"></a>

### 27.4.4. CREATE INDEX Progress Reporting

Whenever `CREATE INDEX` or `REINDEX` is running, the pg_stat_progress_create_index view will contain one row for each backend that is currently creating indexes. The tables below describe the information that will be reported and provide information about how to interpret it. 

<a id="pg-stat-progress-create-index-view"></a>

**pg_stat_progress_create_index View**

| Column Type | Description | 
| --- | --- |
| `pid` `integer` | Process ID of the backend creating indexes. |
| `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` | Specific command type: `CREATE INDEX`, `CREATE INDEX CONCURRENTLY`, `REINDEX`, or `REINDEX CONCURRENTLY`. |
| `phase` `text` | Current processing phase of index creation. See [Table 27.48](progress-reporting.md#create-index-phases). |
| `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` | Total number of partitions on which the index is to be created or attached, including both direct and indirect partitions. `0` during a `REINDEX`, or when the index is not partitioned. |
| `partitions_done` `bigint` | Number of partitions on which the index has already been created or attached, including both direct and indirect partitions. `0` during a `REINDEX`, or when the index is not partitioned. |

<a id="create-index-phases"></a>

**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. | 

<a id="repack-progress-reporting"></a>

### 27.4.5. REPACK Progress Reporting

Whenever `REPACK` is running, the pg_stat_progress_repack view will contain a row for each backend that is currently running the command. The tables below describe the information that will be reported and provide information about how to interpret it. 

<a id="pg-stat-progress-repack-view"></a>

**pg_stat_progress_repack 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 repacked. |
| `command` `text` | The command that is running. Either `REPACK` or `VACUUM FULL`, or `CLUSTER`. |
| `phase` `text` | Current processing phase. See [Table 27.50](progress-reporting.md#repack-phases). |
| `repack_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_inserted` `bigint` | Number of heap tuples inserted. This counter only advances when the phase is `seq scanning heap`, `index scanning heap`, `writing new heap` or `catch-up`. |
| `heap_tuples_updated` `bigint` | Number of heap tuples updated. This counter only advances when the phase is `catch-up`. |
| `heap_tuples_deleted` `bigint` | Number of heap tuples deleted. This counter only advances when the phase is `catch-up`. |
| `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`. |

<a id="repack-phases"></a>

**REPACK Phases**

| Phase | Description | 
| --- | --- |
| `initializing` | The command is preparing to begin scanning the heap. This phase is expected to be very brief. | 
| `seq scanning heap` | The command is currently scanning the table using a sequential scan. | 
| `index scanning heap` | `REPACK` is currently scanning the table using an index scan. | 
| `sorting tuples` | `REPACK` is currently sorting tuples. | 
| `writing new heap` | `REPACK` is currently writing the new heap. | 
| `catch-up` | `REPACK CONCURRENTLY` is currently processing the DML commands that other transactions executed during any of the preceding phases. | 
| `swapping relation files` | The command is currently swapping newly-built files into place. | 
| `rebuilding index` | The command is currently rebuilding an index. | 
| `performing final cleanup` | The command is performing final cleanup. When this phase is completed, `REPACK` will end. | 

<a id="vacuum-progress-reporting"></a>

### 27.4.6. 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.2](progress-reporting.md#cluster-progress-reporting). 

<a id="pg-stat-progress-vacuum-view"></a>

**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.52](progress-reporting.md#vacuum-phases). |
| `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](storage-vm.md) 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` (`integer`)](runtime-config-resource.md#guc-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](runtime-config-vacuum.md#runtime-config-resource-vacuum-cost)), in milliseconds (if [`track_cost_delay_timing` (`boolean`)](runtime-config-statistics.md#guc-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. |
| `mode` `text` | The mode in which the current `VACUUM` operation is running. See [Section 24.1.5](routine-vacuuming.md#vacuum-for-wraparound) for details of each mode. Possible values are: - `normal`: The operation is performing a standard vacuum. It is neither required to run in aggressive mode nor operating in failsafe mode. - `aggressive`: The operation is running an aggressive vacuum, which must scan every page that is not marked all-frozen. The parameters [`vacuum_freeze_table_age` (`integer`)](runtime-config-vacuum.md#guc-vacuum-freeze-table-age) and [`vacuum_multixact_freeze_table_age` (`integer`)](runtime-config-vacuum.md#guc-vacuum-multixact-freeze-table-age) determine when a table requires aggressive vacuuming. - `failsafe`: The vacuum has entered failsafe mode, in which it performs only the minimum work necessary to avoid transaction ID or multixact ID wraparound failure. The parameters [`vacuum_failsafe_age` (`integer`)](runtime-config-vacuum.md#guc-vacuum-failsafe-age) and [`vacuum_multixact_failsafe_age` (`integer`)](runtime-config-vacuum.md#guc-vacuum-multixact-failsafe-age) determine when the vacuum enters failsafe mode. The vacuum may start in this mode or switch to it while running; the value of the `mode` column may transition from another mode to `failsafe` during the operation. |
| `started_by` `text` | Shows what caused the current `VACUUM` operation to be started. Possible values are: - `manual`: The vacuum was started by an explicit `VACUUM` command. - `autovacuum`: The vacuum was started by an autovacuum worker. Vacuums run by autovacuum workers may be interrupted due to lock conflicts. - `autovacuum_wraparound`: The vacuum was started by an autovacuum worker to prevent transaction ID or multixact ID wraparound. Vacuums run for wraparound protection are not interrupted due to lock conflicts. |

<a id="vacuum-phases"></a>

**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` (`integer`)](runtime-config-resource.md#guc-maintenance-work-mem) (or, in the case of autovacuum, [`autovacuum_work_mem` (`integer`)](runtime-config-resource.md#guc-autovacuum-work-mem) if set) 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 cumulative statistics system. When this phase is completed, `VACUUM` will end. | 

<a id="basebackup-progress-reporting"></a>

### 27.4.7. Base Backup Progress Reporting

Whenever an application like pg_basebackup is taking a base backup, the pg_stat_progress_basebackup view will contain a row for each WAL sender process that is currently running the `BASE_BACKUP` replication command and streaming the backup. The tables below describe the information that will be reported and provide information about how to interpret it. 

<a id="pg-stat-progress-basebackup-view"></a>

**pg_stat_progress_basebackup View**

| Column Type | Description | 
| --- | --- |
| `pid` `integer` | Process ID of a WAL sender process. |
| `phase` `text` | Current processing phase. See [Table 27.54](progress-reporting.md#basebackup-phases). |
| `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`. |
| `backup_type` `text` | Backup type. Either `full` or `incremental`. |

<a id="basebackup-phases"></a>

**Base Backup Phases**

| Phase | Description | 
| --- | --- |
| `initializing` | The WAL sender process is preparing to begin the backup. This phase is expected to be very brief. | 
| `waiting for checkpoint to finish` | The WAL sender process is currently performing `pg_backup_start` to prepare to take a base backup, and waiting for the start-of-backup checkpoint to finish. | 
| `estimating backup size` | The WAL sender process is currently estimating the total amount of database files that will be streamed as a base backup. | 
| `streaming database files` | The WAL sender process is currently streaming database files as a base backup. | 
| `waiting for wal archiving to finish` | The WAL sender process is currently performing `pg_backup_stop` to finish the backup, and waiting for all the WAL files required for the base backup to be successfully archived. If either `--wal-method=none` or `--wal-method=stream` is specified in pg_basebackup, the backup will end when this phase is completed. | 
| `transferring wal files` | The WAL sender process is currently transferring all WAL logs generated during the backup. This phase occurs after `waiting for wal archiving to finish` phase if `--wal-method=fetch` is specified in pg_basebackup. The backup will end when this phase is completed. | 

<a id="data-checksum-progress-reporting"></a>

### 27.4.8. Data Checksum Progress Reporting

When data checksums are being enabled or disabled on a running cluster, the pg_stat_progress_data_checksums view will contain a row for the launcher process. When enabling data checksums, the view will also contain one row for each worker process which is currently calculating and writing checksums for the data pages in a database. The launcher provides an overview of the overall progress, such as how many databases have been processed and how many remain, while the workers track progress for currently processed databases. 

<a id="pg-stat-progress-data-checksums-view"></a>

**pg_stat_progress_data_checksums View**

| Column Type | Description | 
| --- | --- |
| `pid` `integer` | Process ID of the data checksum process, launcher or worker. |
| `datid` `oid` | OID of this database, or `0` for the launcher process. |
| `datname` `name` | Name of this database, or `NULL` for the launcher process. |
| `phase` `text` | Current processing phase, see [Table 27.56](progress-reporting.md#datachecksum-phases) for description of the phases. |
| `databases_total` `bigint` | The total number of databases which will be processed. Only the launcher process has this value set when enabling data checksums; otherwise this is set to `NULL`. |
| `databases_done` `bigint` | The number of databases which have been processed. Only the launcher process has this value set when enabling data checksums; otherwise this is set to `NULL`. |
| `relations_total` `bigint` | The total number of relations which will be processed, or `NULL` if the worker process hasn't calculated the number of relations yet. The launcher process has this set to `NULL` since it isn't responsible for processing relations, only launching worker processes. |
| `relations_done` `bigint` | The number of relations which have been processed. The launcher process has this set to `NULL`. |
| `blocks_total` `bigint` | The number of blocks in the current relation which will be processed, or `NULL` if the worker process hasn't calculated the number of blocks yet. The launcher process has this set to `NULL`. |
| `blocks_done` `bigint` | The number of blocks in the current relation which have been processed. The launcher process has this set to `NULL`. |

<a id="datachecksum-phases"></a>

**Data Checksum Phases**

| Phase | Description | 
| --- | --- |
| `enabling` | The command is currently enabling data checksums on the cluster. | 
| `disabling` | The command is currently disabling data checksums on the cluster. | 
| `done` | The command is done and the data checksum state in the cluster has changed. | 
| `waiting on barrier` | The command is currently waiting for the current active backends to acknowledge the change in data checksum state. | 
| `waiting on temporary tables` | The command is currently waiting for all temporary tables which existed at the time the command was started to be removed. |