Re: Add index scan progress to pg_stat_progress_vacuum

> Similar to above three cases, vacuum can bypass index vacuuming if
> there are almost zero TIDs. Should we set indexes_total to 0 in this
> case too? If so, I think we can set both indexes_total and
> indexes_completed at the beginning of the index vacuuming/cleanup and
> reset them at the end.

Unlike the other 3 cases, in which the vacuum and cleanup are totally skipped,
a cleanup still occurs when the index vacuum is bypassed. From what I can tell,
this is to allow for things like a gin pending list cleanup even if the index
is not vacuumed. There could be other reasons as well.

if (bypass)
{
/*
* There are almost zero TIDs. Behave as if there were precisely
* zero: bypass index vacuuming, but do index cleanup.
*
* We expect that the ongoing VACUUM operation will finish very
* quickly, so there is no point in considering speeding up as a
* failsafe against wraparound failure. (Index cleanup is expected to
* finish very quickly in cases where there were no ambulkdelete()
* calls.)
*/
vacrel->do_index_vacuuming = false;
}

So it seems like we should still report the total number of indexes as we are currently
doing in the patch.

With that said, the documentation should make this be more clear.

For indexes_total, the description should be:

Number of indexes that will be vacuumed or cleaned up. This value will be
<literal>0</literal> if there are no indexes to vacuum, <literal>INDEX_CLEANUP</literal>
is set to <literal>OFF</literal>, or vacuum failsafe is triggered.
See <xref linkend="guc-vacuum-failsafe-age"/>

For indexes_completed, it should be:

Number of indexes vacuumed in the current vacuum cycle when the
phase is <literal>vacuuming indexes</liternal>, or the number
of indexes cleaned up in the <literal>cleaning up indexes<literal>
phase.

Regards,

--
Sami Imseih
Amazon Web Services: https://aws.amazon.com