Re: Add index scan progress to pg_stat_progress_vacuum

> I took a look at the latest patch set.

> + <entry role="catalog_table_entry"><para role="column_definition">
> + <structfield>indexes_total</structfield> <type>bigint</type>
> + </para>
> + <para>
> + The number of indexes to be processed in the
> + <literal>vacuuming indexes</literal>
> + or <literal>cleaning up indexes</literal> phase. It is set to
> + <literal>0</literal> when vacuum is not in any of these phases.
> + </para></entry>

> Could we avoid resetting it to 0 unless INDEX_CLEANUP was turned off or
> failsafe kicked in? It might be nice to know how many indexes the vacuum
> intends to process. I don't feel too strongly about this, so if it would
> add a lot of complexity, it might be okay as is.

Your suggestion is valid. On INDEX_CLEANUP it is set to 0 from the start and when failsafe kicks in it will be reset to 0. I Will remove the reset call for the common index vacuum path.

> BTreeShmemInit();
> SyncScanShmemInit();
> AsyncShmemInit();
> + vacuum_worker_init();

> Don't we also need to add the size of the hash table to
> CalculateShmemSize()?

No, ShmemInitHash takes the min and max size of the hash and in turn calls ShmemInitStruct to setup the shared memory.

> + * A command type can optionally define a callback function
> + * which will derive Datum values rather than use values
> + * directly from the backends progress array.

> I think this can be removed.

Good catch.

--
Sami Imseih
Amazon Web Services