Re: Add index scan progress to pg_stat_progress_vacuum
От | Nathan Bossart |
---|---|
Тема | Re: Add index scan progress to pg_stat_progress_vacuum |
Дата | |
Msg-id | 20220310005237.GA307769@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Add index scan progress to pg_stat_progress_vacuum ("Imseih (AWS), Sami" <simseih@amazon.com>) |
Ответы |
Re: Add index scan progress to pg_stat_progress_vacuum
Re: Add index scan progress to pg_stat_progress_vacuum |
Список | pgsql-hackers |
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. BTreeShmemInit(); SyncScanShmemInit(); AsyncShmemInit(); + vacuum_worker_init(); Don't we also need to add the size of the hash table to CalculateShmemSize()? + * 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. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: