> 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
