MIME-Version: 1.0
References: 
 <CALj2ACUgwSchK6jQ2CdKLBWUADTOE_zKdTff2Zg3E6hOuXKv-w@mail.gmail.com>
In-Reply-To: 
 <CALj2ACUgwSchK6jQ2CdKLBWUADTOE_zKdTff2Zg3E6hOuXKv-w@mail.gmail.com>
From: Sami Imseih <samimseih@gmail.com>
Date: Tue, 5 May 2026 12:54:25 -0500
Message-ID: 
 <CAA5RZ0vh8cNV0DuTuebCfi=XVkQhYD5TWUx7+DHSE1D56c88-w@mail.gmail.com>
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0vh8cNV0DuTuebCfi%3DXVkQhYD5TWUx7%2BDHSE1D56c88-w%40mail.gmail.com>
Precedence: bulk

Hi,

> Appreciate any feedback. Thank you!

I think it is valuable to show the index being processed. There is
really no other easy way to get this information except for pstack,
etc. I am +1 for the idea.

However, I am not sure that having a separate row for every parallel
worker is the right approach. The pg_stat_progress_* views are designed
to show progress per row. Each row represents one command with
meaningful progress counters (heap_blks_scanned, indexes_total,
indexes_processed, etc.). A parallel worker row would only show
current_index_relid and leader_pid with no actual progress information
of its own. That is status, not progress, and it does not fit the
view. Also, many columns would remain empty or redundant with the
leader's row.

Instead, could we  aggregate the parallel worker information into the
leader's row. For example, an array of worker PIDs in one column and an
array of index relids in another?

--
Sami Imseih
Amazon Web Services (AWS)