Re: Report index currently being vacuumed in pg_stat_progress_vacuum

On Wed, Sep 02, 2026 at 07:23:00PM -0700, Bharath Rupireddy wrote:
> Thanks Michael for the off-list chat. I agree that emitting leader_pid
> via the vacuum progress report is information bloat, since one can
> easily identify the workers for a given leader by looking at the
> database OID and relation name, and if needed, can also join with
> pg_stat_activity.leader_pid. So, I removed leader_pid in the 0001
> patch.

Full disclosure. I have discussed this patch set a bit with Bharath.
The discussion can be summed up like:
- leader_pid in the progress view with a JOIN to pg_stat_activity
feels like bloating the view with duplicated information.
- The database OID, the relation OID and the index OID gain in
visibility by being specified in the lines for the workers. Note: it
looks like we are doing so based on your output posted upthread,
missed that during our discussion, initially.
- The two new fields for total index blocks and index blocks processed
make more sense than trying to reuse the heap attributes because a
leader may do itself some of the cleanup. Multiple passes are less
likely lately, but could still be possible, and we want to know where
the leader is at for the heap part while working on the indexes.

Reading through v5-0001 and v5-0002, it looks like all these check
boxes are ticked. In terms of review clarity, splitting both patches
slightly helps, but I'd rather merge both things together at the end:
the first patch gains a lot in value thanks to the second patch where
the two block aggregates are added.

Perhaps I am missing something else? In this case, please feel free
to overwrite my words..
--
Michael