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 422CE0B2-60A7-4E87-B5B1-5393DDF1DA21@amazon.com
Whole thread Raw
In response to Re: Add index scan progress to pg_stat_progress_vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses 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  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Thank you for the feedback!

>    I think we can pass the progress update function to
>   WaitForParallelWorkersToFinish(), which seems simpler. And we can call

Directly passing the callback to WaitForParallelWorkersToFinish
will require us to modify the function signature.

To me, it seemed simpler and touches less code to have
the caller set the callback in the ParallelContext.

>    the function after updating the index status to
>    PARALLEL_INDVAC_STATUS_COMPLETED.

I also like this better. Will make the change.

>    BTW, currently we don't need a lock for touching index status since
>    each worker touches different indexes. But after this patch, the
>    leader will touch all index status, do we need a lock for that?

I do not think locking is needed here. The leader and workers
will continue to touch different indexes to update the status.

However, if the process is a leader, it will call the function
which will go through indstats and count how many
Indexes have a status of PARALLEL_INDVAC_STATUS_COMPLETED.
This value is then reported to the leaders backend only.


Regards,

Sami Imseih
Amazon Web Services


pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: [PATCH] Add initial xid/mxid/mxoff to initdb
Next
From: Przemysław Sztoch
Date:
Subject: Re: [PATCH] Completed unaccent dictionary with many missing characters