PostgreSQL
28.4. Progress Reporting
PostgreSQL has the ability to report the progress of certain commands during command execution. Currently, the only command which supports progress reporting is VACUUM
. This may be expanded in the future.
28.4.1. 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 reporting is not currently supported for VACUUM FULL
and backends running VACUUM FULL
will not be listed in this view.
Table 28.21. 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 28.22. |
|
|
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 28.22. VACUUM phases
Phase | Description |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+
Prev | Up | Next |
---|---|---|
28.3. Viewing Locks |
28.5. Dynamic Tracing |
Copyright © 1996-2023 The PostgreSQL Global Development Group