PostgreSQL has the ability to report the progress of
   certain commands during command execution.  Currently, the only commands
   which support progress reporting are ANALYZE,
   CLUSTER,
   CREATE INDEX, VACUUM,
   COPY,
   and BASE_BACKUP (i.e., replication
   command that pg_basebackup issues to take
   a base backup).
   This may be expanded in the future.
  
   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.
  
Table 27.38. pg_stat_progress_analyze View
| Column Type Description | 
|---|
| 
        Process ID of backend. | 
| 
        OID of the database to which this backend is connected. | 
| 
        Name of the database to which this backend is connected. | 
| 
        OID of the table being analyzed. | 
| 
        Current processing phase. See Table 27.39. | 
| 
        Total number of heap blocks that will be sampled. | 
| 
        Number of heap blocks scanned. | 
| 
        Number of extended statistics. | 
| 
        
       Number of extended statistics computed. This counter only advances
       when the phase is  | 
| 
        Number of child tables. | 
| 
        
       Number of child tables scanned. This counter only advances when the
       phase is  | 
| 
        
       OID of the child table currently being scanned. This field is
       only valid when the phase is
        | 
Table 27.39. 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 relidto 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, andcurrent_child_table_relidcontain 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,ANALYZEwill end. | 
    Note that when ANALYZE is run on a partitioned table,
    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.
   
   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.40. pg_stat_progress_cluster View
| Column Type Description | 
|---|
| 
        Process ID of backend. | 
| 
        OID of the database to which this backend is connected. | 
| 
        Name of the database to which this backend is connected. | 
| 
        OID of the table being clustered. | 
| 
        
       The command that is running. Either  | 
| 
        Current processing phase. See Table 27.41. | 
| 
        If the table is being scanned using an index, this is the OID of the index being used; otherwise, it is zero. | 
| 
        
       Number of heap tuples scanned.
       This counter only advances when the phase is
        | 
| 
        
       Number of heap tuples written.
       This counter only advances when the phase is
        | 
| 
        
       Total number of heap blocks in the table.  This number is reported
       as of the beginning of  | 
| 
        
       Number of heap blocks scanned.  This counter only advances when the
       phase is  | 
| 
        
       Number of indexes rebuilt.  This counter only advances when the phase
       is  | 
Table 27.41. 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 | CLUSTERis currently scanning the table using an index scan. | 
| sorting tuples | CLUSTERis currently sorting tuples. | 
| writing new heap | CLUSTERis 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, CLUSTERorVACUUM FULLwill end. | 
   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.
  
Table 27.42. pg_stat_progress_copy View
| Column Type Description | 
|---|
| 
        Process ID of backend. | 
| 
        OID of the database to which this backend is connected. | 
| 
        Name of the database to which this backend is connected. | 
| 
        
       OID of the table on which the  | 
| 
        
       The command that is running:  | 
| 
        
       The I/O type that the data is read from or written to:
        | 
| 
        
       Number of bytes already processed by  | 
| 
        
       Size of source file for  | 
| 
        
       Number of tuples already processed by  | 
| 
        
       Number of tuples not processed because they were excluded by the
        | 
| 
        
       Number of tuples skipped because they contain malformed data.
       This counter only advances when a value other than
        | 
   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.
  
Table 27.43. pg_stat_progress_create_index View
| Column Type Description | 
|---|
| 
        Process ID of the backend creating indexes. | 
| 
        OID of the database to which this backend is connected. | 
| 
        Name of the database to which this backend is connected. | 
| 
        OID of the table on which the index is being created. | 
| 
        
       OID of the index being created or reindexed.  During a
       non-concurrent  | 
| 
        
       Specific command type:  | 
| 
        Current processing phase of index creation. See Table 27.44. | 
| 
        Total number of lockers to wait for, when applicable. | 
| 
        Number of lockers already waited for. | 
| 
        Process ID of the locker currently being waited for. | 
| 
        Total number of blocks to be processed in the current phase. | 
| 
        Number of blocks already processed in the current phase. | 
| 
        Total number of tuples to be processed in the current phase. | 
| 
        Number of tuples already processed in the current phase. | 
| 
        
       Total number of partitions on which the index is to be created
       or attached, including both direct and indirect partitions.
        | 
| 
        
       Number of partitions on which the index has already been created
       or attached, including both direct and indirect partitions.
        | 
Table 27.44. CREATE INDEX Phases
| Phase | Description | 
|---|---|
| initializing | CREATE INDEXorREINDEXis preparing to create the index.  This
       phase is expected to be very brief. | 
| waiting for writers before build | CREATE INDEX CONCURRENTLYorREINDEX CONCURRENTLYis waiting for transactions
       with write locks that can potentially see the table to finish.
       This phase is skipped when not in concurrent mode.
       Columnslockers_total,lockers_doneandcurrent_locker_pidcontain 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_totalandblocks_donewill contain progress data, as well as potentiallytuples_totalandtuples_done. | 
| waiting for writers before validation | CREATE INDEX CONCURRENTLYorREINDEX CONCURRENTLYis waiting for transactions
       with write locks that can potentially write into the table to finish.
       This phase is skipped when not in concurrent mode.
       Columnslockers_total,lockers_doneandcurrent_locker_pidcontain the progress
       information for this phase. | 
| index validation: scanning index | CREATE INDEX CONCURRENTLYis scanning the index searching
       for tuples that need to be validated.
       This phase is skipped when not in concurrent mode.
       Columnsblocks_total(set to the total size of the index)
       andblocks_donecontain the progress information for this phase. | 
| index validation: sorting tuples | CREATE INDEX CONCURRENTLYis sorting the output of the
       index scanning phase. | 
| index validation: scanning table | CREATE INDEX CONCURRENTLYis scanning the table
       to validate the index tuples collected in the previous two phases.
       This phase is skipped when not in concurrent mode.
       Columnsblocks_total(set to the total size of the table)
       andblocks_donecontain the progress information for this phase. | 
| waiting for old snapshots | CREATE INDEX CONCURRENTLYorREINDEX CONCURRENTLYis waiting for transactions
       that can potentially see the table to release their snapshots.  This
       phase is skipped when not in concurrent mode.
       Columnslockers_total,lockers_doneandcurrent_locker_pidcontain the progress
       information for this phase. | 
| waiting for readers before marking dead | REINDEX CONCURRENTLYis 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.
       Columnslockers_total,lockers_doneandcurrent_locker_pidcontain the progress
       information for this phase. | 
| waiting for readers before dropping | REINDEX CONCURRENTLYis 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.
       Columnslockers_total,lockers_doneandcurrent_locker_pidcontain the progress
       information for this phase. | 
   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.
  
Table 27.45. pg_stat_progress_vacuum View
| Column Type Description | 
|---|
| 
        Process ID of backend. | 
| 
        OID of the database to which this backend is connected. | 
| 
        Name of the database to which this backend is connected. | 
| 
        OID of the table being vacuumed. | 
| 
        Current processing phase of vacuum. See Table 27.46. | 
| 
        
       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  | 
| 
        
       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  | 
| 
        
       Number of heap blocks vacuumed.  Unless the table has no indexes, this
       counter only advances when the phase is  | 
| 
        Number of completed index vacuum cycles. | 
| 
        Amount of dead tuple data that we can store before needing to perform an index vacuum cycle, based on maintenance_work_mem. | 
| 
        Amount of dead tuple data collected since the last index vacuum cycle. | 
| 
       Number of dead item identifiers collected since the last index vacuum cycle. | 
| 
        
       Total number of indexes that will be vacuumed or cleaned up. This
       number is reported at the beginning of the
        | 
| 
        
       Number of indexes processed. This counter only advances when the
       phase is  | 
Table 27.46. VACUUM Phases
| Phase | Description | 
|---|---|
| initializing | VACUUMis preparing to begin scanning the heap.  This
       phase is expected to be very brief. | 
| scanning heap | VACUUMis currently scanning the heap.  It will prune and
       defragment each page if required, and possibly perform freezing
       activity.  Theheap_blks_scannedcolumn can be used
       to monitor the progress of the scan. | 
| vacuuming indexes | VACUUMis 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 (or, in the case of autovacuum,
       autovacuum_work_mem if set) is insufficient to store
       the number of dead tuples found. | 
| vacuuming heap | VACUUMis currently vacuuming the heap.  Vacuuming the heap
       is distinct from scanning the heap, and occurs after each instance of
       vacuuming indexes.  Ifheap_blks_scannedis less thanheap_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 | VACUUMis 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 | VACUUMis 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 | VACUUMis performing final cleanup.  During this phase,VACUUMwill vacuum the free space map, update statistics
       inpg_class, and report statistics to the cumulative
       statistics system. When this phase is completed,VACUUMwill end. | 
   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.
  
Table 27.47. pg_stat_progress_basebackup View
| Column Type Description | 
|---|
| 
        Process ID of a WAL sender process. | 
| 
        Current processing phase. See Table 27.48. | 
| 
        
       Total amount of data that will be streamed. This is estimated and
       reported as of the beginning of
        | 
| 
        
       Amount of data streamed. This counter only advances
       when the phase is  | 
| 
        Total number of tablespaces that will be streamed. | 
| 
        
       Number of tablespaces streamed. This counter only
       advances when the phase is  | 
Table 27.48. 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_startto 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_stopto finish the backup,
       and waiting for all the WAL files required for the base backup
       to be successfully archived.
       If either--wal-method=noneor--wal-method=streamis 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 finishphase if--wal-method=fetchis specified in
       pg_basebackup. The backup will end
       when this phase is completed. |