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
,
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.
표 27.32. 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 표 27.33. |
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
|
표 27.33. 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 that when ANALYZE
is run on a partitioned table,
all of its partitions are also recursively analyzed as also mentioned in
ANALYZE. 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 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.
표 27.34. pg_stat_progress_create_index
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 index is being created. |
OID of the index being created or reindexed. During a
non-concurrent |
The command that is running: |
Current processing phase of index creation. See 표 27.35. |
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. |
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. |
When creating an index on a partitioned table, this column is set to the number of partitions on which the index has been completed. |
표 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.
|
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 27.4.4절.
표 27.36. 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 표 27.37. |
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. |
Number of dead tuples that we can store before needing to perform an index vacuum cycle, based on maintenance_work_mem. |
Number of dead tuples collected since the last index vacuum cycle. |
표 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 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.
|
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.
표 27.38. 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 표 27.39. |
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 |
표 27.39. 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.
|
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.
표 27.40. pg_stat_progress_basebackup
View
Column Type Description |
---|
Process ID of a WAL sender process. |
Current processing phase. See 표 27.41. |
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 |
표 27.41. 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_start_backup 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_stop_backup 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.
|