transactions
       with read locks on the table to finish, before dropping the old index.
       This phase is skipped when not in concurrent mode.
       Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
       and <structname>current_locker_pid</structname> contain the progress
       information for this phase.
      </entry>
     </row>
    </tbody>
   </tgroup>
  </table>

 </sect2>

 <sect2 id="vacuum-progress-reporting">
  <title>VACUUM Progress Reporting</title>

  <indexterm>
   <primary>pg_stat_progress_vacuum</primary>
  </indexterm>

  <para>
   Whenever <command>VACUUM</command> is running, the
   <structname>pg_stat_progress_vacuum</structname> 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 <command>VACUUM FULL</command> commands is reported via
   <structname>pg_stat_progress_cluster</structname>
   because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
   rewrite the table, while regular <command>VACUUM</command> only modifies it
   in place. See <xref linkend="cluster-progress-reporting"/>.
  </para>

  <table id="pg-stat-progress-vacuum-view" xreflabel="pg_stat_progress_vacuum">
   <title><structname>pg_stat_progress_vacuum</structname> View</title>
   <tgroup cols="1">
    <thead>
     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       Column Type
      </para>
      <para>
       Description
      </para></entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>pid</structfield> <type>integer</type>
      </para>
      <para>
       Process ID of backend.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>datid</structfield> <type>oid</type>
      </para>
      <para>
       OID of the database to which this backend is connected.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>datname</structfield> <type>name</type>
      </para>
      <para>
       Name of the database to which this backend is connected.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>relid</structfield> <type>oid</type>
      </para>
      <para>
       OID of the table being vacuumed.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>phase</structfield> <type>text</type>
      </para>
      <para>
       Current processing phase of vacuum.  See <xref linkend="vacuum-phases"/>.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>heap_blks_total</structfield> <type>bigint</type>
      </para>
      <para>
       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 <command>VACUUM</command>.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>heap_blks_scanned</structfield> <type>bigint</type>
      </para>
      <para>
       Number of heap blocks scanned.  Because the
       <link linkend="storage-vm">visibility map</link> 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 <structfield>heap_blks_total</structfield> when the vacuum is complete.
       This counter only advances when