PostgreSQL有能力在命令执行期间报告特定命令的进度。当前，唯一一种支持进度报告的命令是VACUUM。这在未来可能会被扩充。
只要VACUUM正在运行，每一个当前正在清理的后端（包括autovacuum工作者进程）在pg_stat_progress_vacuum视图中都会有一行。下面的表描述了将被报告的信息并且提供了如何解释它们的信息。进度报告当前不支持VACUUM FULL，运行着VACUUM FULL的后端将不会在这个视图中列出。
Table 28.21. pg_stat_progress_vacuum视图
| 列 | 类型 | 描述 |
|---|---|---|
pid | integer | 后端的进程ID。 |
datid | oid | 这个后端连接的数据库的OID。 |
datname | name | 这个后端连接的数据库的名称。 |
relid | oid | 被vacuum的表的OID。 |
phase | text | vacuum的当前处理阶段。请参考Table 28.22。 |
heap_blks_total | bigint |
该表中堆块的总数。这个数字在扫描开始时报告，之后增加的块将不会（并且不需要）被这个VACUUM访问。
|
heap_blks_scanned | bigint |
被扫描的堆块数量。由于可见性映射被用来优化扫描，一些块将被跳过而不做检查，被跳过的块会被包括在这个总数中，因此当清理完成时这个数字最终将会等于heap_blks_total。仅当处于扫描堆阶段时这个计数器才会前进。
|
heap_blks_vacuumed | bigint |
被清理的堆块数量。除非表没有索引，这个计数器仅在处于清理堆阶段时才会前进。不包含死亡元组的块会被跳过，因此这个计数器可能有时会向前跳跃一个比较大的增量。
|
index_vacuum_count | bigint | 已完成的索引清理周期数。 |
max_dead_tuples | bigint | 在需要执行一个索引清理周期之前我们可以存储的死亡元组数，取决于maintenance_work_mem。 |
num_dead_tuples | bigint | 从上一个索引清理周期以来收集的死亡元组数。 |
Table 28.22. VACUUM的阶段
| 阶段 | 描述 |
|---|---|
初始化 |
VACUUM正在准备开始扫描堆。这个阶段应该很简短。
|
扫描堆 |
VACUUM正在扫描堆。如果需要，它将会对每个页面进行修建以及碎片整理，并且可能会执行冻结动作。heap_blks_scanned列可以用来监控扫描的进度。
|
清理索引 |
VACUUM当前正在清理索引。如果一个表拥有索引，那么每次清理时这个阶段会在堆扫描完成后至少发生一次。如果maintenance_work_mem不足以存放找到的死亡元组，则每次清理时会多次清理索引。
|
清理堆 |
VACUUM当前正在清理堆。清理堆与扫描堆不是同一个概念，清理堆发生在每一次清理索引的实例之后。如果heap_blks_scanned小于heap_blks_total，系统将在这个阶段完成之后回去扫描堆；否则，系统将在这个阶段完成后开始清理索引。
|
清除索引 |
VACUUM当前正在清除索引。这个阶段发生在堆被完全扫描并且对堆和索引的所有清理都已经完成以后。
|
截断堆 |
VACUUM正在截断堆，以便把关系尾部的空页面返还给操作系统。这个阶段发生在清除完索引之后。
|
执行最后的清除 |
VACUUM在执行最终的清除。在这个阶段中，VACUUM将清理空闲空间映射、更新pg_class中的统计信息并且将统计信息报告给统计收集器。当这个阶段完成时，VACUUM也就结束了。
|