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
, 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.
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.
Table 27.32. pg_stat_progress_analyze
View
pg_stat_progress_analyze
ViewColumn 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.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 |
Table 27.33. ANALYZE phases
Phase | Description |
---|---|
| The command is preparing to begin scanning the heap. This phase is expected to be very brief. |
| The command is currently scanning the table given by |
| The command is currently scanning child tables to obtain sample rows. Columns |
| The command is computing statistics from the sample rows obtained during the table scan. |
| The command is computing extended statistics from the sample rows obtained during the table scan. |
| The command is updating |
Note
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.
27.4.2. CREATE INDEX Progress Reporting
每當執行 CREATE INDEX 或 REINDEX 時,pg_stat_progress_create_index 檢視表的每一行會列出目前正在建立索引的每個後端程序。下表描述了其所回報的資訊,以及有關如何解釋的說明。
Table 27.34. pg_stat_progress_create_index
View
pg_stat_progress_create_index
ViewColumn 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 Table 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. |
Table 27.35. CREATE INDEX Phases
Phase | Description |
---|---|
|
|
|
|
| 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, |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
Table 27.36. pg_stat_progress_vacuum
View
pg_stat_progress_vacuum
ViewColumn 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.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. |
Table 27.37. VACUUM Phases
Phase | Description |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
pg_stat_progress_cluster
ViewColumn 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.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 |
Table 27.39. CLUSTER and VACUUM FULL Phases
Phase | Description |
---|---|
| The command is preparing to begin scanning the heap. This phase is expected to be very brief. |
| The command is currently scanning the table using a sequential scan. |
|
|
|
|
|
|
| The command is currently swapping newly-built files into place. |
| The command is currently rebuilding an index. |
| The command is performing final cleanup. When this phase is completed, |
27.4.5. 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.
Table 27.40. pg_stat_progress_basebackup
View
pg_stat_progress_basebackup
ViewColumn Type Description |
Process ID of a WAL sender process. |
Current processing phase. See Table 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 |
Table 27.41. Base backup phases
Phase | Description |
---|---|
| The WAL sender process is preparing to begin the backup. This phase is expected to be very brief. |
| The WAL sender process is currently performing |
| The WAL sender process is currently estimating the total amount of database files that will be streamed as a base backup. |
| The WAL sender process is currently streaming database files as a base backup. |
| The WAL sender process is currently performing |
| The WAL sender process is currently transferring all WAL logs generated during the backup. This phase occurs after |
Last updated