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
signature.asc
Description: PGP signature
