Re: Add index scan progress to pg_stat_progress_vacuum

Поиск
Список
Период
Сортировка
От Imseih (AWS), Sami
Тема Re: Add index scan progress to pg_stat_progress_vacuum
Дата
Msg-id 0601FEDE-5DE8-4F03-9F7C-7A927302475C@amazon.com
обсуждение исходный текст
Ответ на Re: Add index scan progress to pg_stat_progress_vacuum  (Andres Freund <andres@anarazel.de>)
Ответы Re: Add index scan progress to pg_stat_progress_vacuum  (Robert Haas <robertmhaas@gmail.com>)
Re: Add index scan progress to pg_stat_progress_vacuum  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
>    I nevertheless think that's not acceptable. The whole premise of the progress
>    reporting infrastructure is to be low overhead. It's OK to require locking to
>    initialize parallel progress reporting, it's definitely not ok to require
>    locking to report progress.

Fair point.

>    Why isn't the obvious thing to do here to provide a way to associate workers
>    with their leaders in shared memory, but to use the existing progress fields
>    to report progress? Then, when querying progress, the leader and workers
>    progress fields can be combined to show the overall progress?

The original intent was this, however the workers 
can exit before the command completes and the 
worker progress data will be lost.
This is why the shared memory was introduced. 
This allows the worker progress to persist for the duration 
of the command.

Regards, 

Sami Imseih
Amazon Web Services.





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: How to generate a WAL record spanning multiple WAL files?
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file