Re: Add index scan progress to pg_stat_progress_vacuum - Mailing list pgsql-hackers

From Imseih (AWS), Sami
Subject Re: Add index scan progress to pg_stat_progress_vacuum
Date
Msg-id 72CD33F6-C2B5-45E4-A78F-85EC923DCF0F@amazon.com
Whole thread Raw
In response to Re: Add index scan progress to pg_stat_progress_vacuum  (Andres Freund <andres@anarazel.de>)
Responses Re: Add index scan progress to pg_stat_progress_vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Thanks for the feedback and I apologize for the delay in response.

>    I think the problem here is that you're basically trying to work around the
>    lack of an asynchronous state update mechanism between leader and workers. The
>    workaround is to add a lot of different places that poll whether there has
>    been any progress. And you're not doing that by integrating with the existing
>    machinery for interrupt processing (i.e. CHECK_FOR_INTERRUPTS()), but by
>    developing a new mechanism.

>    I think your best bet would be to integrate with HandleParallelMessages().

You are correct. I have been trying to work around the async nature
of parallel workers performing the index vacuum. As you have pointed out,
integrating with HandleParallelMessages does appear to be the proper way.
Doing so will also avoid having to do any progress updates in the index AMs.

In the attached patch, the parallel workers send a new type of protocol message
type to the leader called 'P' which signals the leader that it should handle a
progress update. The leader then performs the progress update by
invoking a callback set in the ParallelContext. This is done inside  HandleParallelMessages.
In the index vacuum case, the callback is parallel_vacuum_update_progress. 

The new message does not contain a payload, and it's merely used to
signal the leader that it can invoke a progress update.

Also, If the leader performs the index vacuum, it can call parallel_vacuum_update_progress
directly inside vacuumparallel.c.

Regards,

Sami Imseih
Amazon Web Services (AWS)





Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Named Operators
Next
From: Andrew Dunstan
Date:
Subject: Re: on placeholder entries in view rule action query's range table