Re: Report index currently being vacuumed in pg_stat_progress_vacuum

On Tue, Sep 15, 2026 at 03:28:00PM -0700, Bharath Rupireddy wrote:
> On Tue, Sep 15, 2026 at 10:11 AM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>> I do think it will be better to do one more split of v6-0001 to separate
>> current_index_relid and index_blks_*; they are 2 distinct features. Also
>> you can fold the 0002 into the index_blks_* commit.
>
> I prefer to keep them as one patch as I see them as closely related,
> but I'm open to splitting if anyone thinks otherwise.

In terms of the "core" patch that introduces the counters, grouping
them together is fine by me.

> I agree with all three comments above and have updated the v6 patches
> accordingly. Please have a look.

Reading through the patches. 0002 is a nice cleanup.

0003 and 0004 are not things I can get much into, echoing with the
recent following message:
https://www.postgresql.org/message-id/aqqmGGS6qqm5LI0Z%40alvherre.pgsql

I think that we should try to think harder regarding what kind of
facility we are looking for:
https://www.postgresql.org/message-id/aqqmGGS6qqm5LI0Z%40alvherre.pgsql

Your proposal based on TAP is not as heavy as the other message, but
I'm worried about the bloat this could create long-term if the same
pattern flourishes in more code paths of the tree (aka 0004 seems
AI-generated to me based on the current facilities we have, I'd
consider more building pieces before that). Switching to python may
make these test patterns much easier compared to perl, though I have
to be honest I have not looked at the recent proposals based on pypi
and such.
--
Michael