<para>
       Total number of indexes that will be vacuumed or cleaned up. This
       number is reported at the beginning of the
       <literal>vacuuming indexes</literal> phase or the
       <literal>cleaning up indexes</literal> phase.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>indexes_processed</structfield> <type>bigint</type>
      </para>
      <para>
       Number of indexes processed. This counter only advances when the
       phase is <literal>vacuuming indexes</literal> or
       <literal>cleaning up indexes</literal>.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>delay_time</structfield> <type>double precision</type>
      </para>
      <para>
       Total time spent sleeping due to cost-based delay (see
       <xref linkend="runtime-config-resource-vacuum-cost"/>), in milliseconds
       (if <xref linkend="guc-track-cost-delay-timing"/> is enabled, otherwise
       zero).  This includes the time that any associated parallel workers have
       slept.  However, parallel workers report their sleep time no more
       frequently than once per second, so the reported value may be slightly
       stale.
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <table id="vacuum-phases">
   <title>VACUUM Phases</title>
   <tgroup cols="2">
    <colspec colname="col1" colwidth="1*"/>
    <colspec colname="col2" colwidth="2*"/>
    <thead>
    <row>
      <entry>Phase</entry>
      <entry>Description</entry>
     </row>
    </thead>

   <tbody>
    <row>
     <entry><literal>initializing</literal></entry>
     <entry>
       <command>VACUUM</command> is preparing to begin scanning the heap.  This
       phase is expected to be very brief.
     </entry>
    </row>
    <row>
     <entry><literal>scanning heap</literal></entry>
     <entry>
       <command>VACUUM</command> is currently scanning the heap.  It will prune and
       defragment each page if required, and possibly perform freezing
       activity.  The <structfield>heap_blks_scanned</structfield> column can be used
       to monitor the progress of the scan.
     </entry>
    </row>
    <row>
     <entry><literal>vacuuming indexes</literal></entry>
     <entry>
       <command>VACUUM</command> 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 <xref linkend="guc-maintenance-work-mem"/> (or, in the case of autovacuum,
       <xref linkend="guc-autovacuum-work-mem"/> if set) is insufficient to store
       the number of dead tuples found.
     </entry>
    </row>
    <row>
     <entry><literal>vacuuming heap</literal></entry>
     <entry>
       <command>VACUUM</command> is currently vacuuming the heap.  Vacuuming the heap
       is distinct from scanning the heap, and occurs after each instance of
       vacuuming indexes.  If <structfield>heap_blks_scanned</structfield> is less than
       <structfield>heap_blks_total</structfield>, 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.
     </entry>
    </row>
    <row>
     <entry><literal>cleaning up indexes</literal></entry>
     <entry>
       <command>VACUUM</command> 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.
     </entry>
    </row>
    <row>
     <entry><literal>truncating heap</literal></entry>
     <entry>
       <command>VACUUM</command> 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.