Re: Report index currently being vacuumed in pg_stat_progress_vacuum - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Date
Msg-id ar29gPEJ3N3CIHf2@paquier.xyz
Whole thread
In response to Re: Report index currently being vacuumed in pg_stat_progress_vacuum  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Re: Report index currently being vacuumed in pg_stat_progress_vacuum
List pgsql-hackers
On Fri, Sep 18, 2026 at 11:23:37AM -0700, Bharath Rupireddy wrote:
> On Thu, Sep 17, 2026 at 6:00 PM shihao zhong <zhong950419@gmail.com> wrote:
>> v7 looks good here. Tested sequential, parallel on btree and GIN, all as the
>> docs describe, including GIN reporting zero blocks and the reset
>> clearing the previous index. Applies cleanly on 5e595d659fd, suites
>> pass.
>
> Thanks for testing v7 on these and for confirming the behavior matches the docs.

I've looked at v7, and my main comment is that this is bloated in
terms of docs and comments.  My hands-on is leading me to the attached
result, that reduces the docs to actually explain what these new
counters do, and only that, including your note at the bottom about
the workers and the relevant fields.  :D

  * Since parallel vacuum workers perform only index vacuum or index cleanup,
- * we don't need to report progress information.
+ * they report progress for the index they are processing.

This reads a bit weird as well..

Just for transparency, I've used the following thing to check the
state of the progress.  One session to create and destroy:
CREATE TABLE pvac (a int, b int, c int, d int[]);
INSERT INTO pvac
  SELECT i, i, i, ARRAY[i, i+1, i+2] FROM generate_series(1, 3000000) i;
CREATE INDEX pvac_a ON pvac (a);
CREATE INDEX pvac_b ON pvac (b);
CREATE INDEX pvac_c ON pvac (c);
CREATE INDEX pvac_d ON pvac USING gin (d);
DELETE FROM pvac WHERE a % 3 = 0;
SET maintenance_work_mem = '1MB';
SET max_parallel_maintenance_workers = 4;
VACUUM (PARALLEL 4, VERBOSE) pvac;

And a second session to monitor (lower \watch for more output):
SELECT a.pid, a.leader_pid, v.phase,
       v.current_index_relid::regclass AS idx,
       v.index_blks_done, v.index_blks_total,
       v.indexes_processed, v.indexes_total,
       v.heap_blks_scanned, v.heap_blks_total
  FROM pg_stat_progress_vacuum v
  JOIN pg_stat_activity a USING (pid)
 WHERE v.relid = 'pvac'::regclass
 ORDER BY a.leader_pid NULLS FIRST, a.pid \watch 0.5

And I'd say that this is pretty nice to see all this information.
Nice result for a limited amount of code added.

Then, I don't really have a lot of feelings for v7-0002.  Even if all
the paths set the progress flag to true in the backend core code,
I think that there is an out-of-core argument in favor of keeping it,
as some code out there may want to control if progress should show up
or not.  And I suspect that we will need it at some point..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: subquery pullup misses lateral refs in join alias Vars
Next
From: David Rowley
Date:
Subject: Re: [PATCH] intXshr, intXshl: return error on shift count out of range