> 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
