Re: Add index scan progress to pg_stat_progress_vacuum

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Add index scan progress to pg_stat_progress_vacuum
Дата
Msg-id CA+TgmoaQDGtKs8qotVBHRzr-G5OnrQNdeknAjM_GKdc0J_ideg@mail.gmail.com
обсуждение исходный текст
Ответ на 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  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Список pgsql-hackers
On Tue, Apr 5, 2022 at 12:42 PM Imseih (AWS), Sami <simseih@amazon.com> wrote:
> >    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.

At the beginning of a parallel operation, we allocate a chunk of
dynamic shared memory which persists even after some or all workers
have exited. It's only torn down at the end of the parallel operation.
That seems like the appropriate place to be storing any kind of data
that needs to be propagated between parallel workers. The current
patch uses the main shared memory segment, which seems unacceptable to
me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
Следующее
От: Andres Freund
Дата:
Сообщение: Re: shared-memory based stats collector - v68