Re: Report index currently being vacuumed in pg_stat_progress_vacuum

Hi,

On Fri, Jul 17, 2026 at 12:24 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>
> See the attached v2.
>
> It aggregates on the leader (if parallel) at the SQL level with two new
> columns: index_vacuum_pids and index_vacuum_oids. These are pid and oid
> arrays respectively and are order-aligned. The leader is listed first when
> it is itself processing an index; otherwise one of the workers is,
> obviously, first.
> For a serial vacuum, each array is a single value. The array fields will be
> NULL if no index is currently being processed.
>
> Using array typed columns is new for the pg_stat_progress_* views, none of
> them expose arrays today, or any other pg_stat_* views. It's a bit unusual here,
> but I think it's the natural fit.

Thanks for the v2 patch, Sami!

I spent some more time thinking about using arrays here, and about the
one-row-per-command policy. I still think emitting the index OIDs and
worker PIDs as position-aligned arrays (like the existing
pg_stats.most_common_vals/most_common_freqs columns) is the simple
solution. I appreciate any thoughts or other ways here.

Please find attached the v3 patch. It ensures the current index is
reset after each index (so vacuuming heap and truncating heap show
NULL arrays with no stale relid), fixes the docs for the type of
index_vacuum_pids, adds a note in the docs about the arrays being
position-aligned, and rewords the commit message a bit.

Here's how the sample output looks.

Index vacuum:

pid | phase | index_vacuum_pids | index_vacuum_oids
------+-------------------+-------------------+-------------------
4955 | vacuuming indexes | {4955} | {16478}
(1 row)

Parallel index vacuum:

pid | phase | index_vacuum_pids | index_vacuum_oids
------+-------------------+-----------------------+---------------------------
5765 | vacuuming indexes | {5765,5768,5769,5770} | {16478,16479,16480,16481}
(1 row)

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com