agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Michael Paquier <michael@paquier.xyz>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Date: Thu, 3 Sep 2026 14:15:30 +0900
Message-ID: <apkCcttASAC6d6J8@paquier.xyz> (raw)
In-Reply-To: <CALj2ACVYtmj=P4u1cBO+MwHFYQw_wzVxhtcV1WWrELbSOvuuzg@mail.gmail.com>
References: <CALj2ACU3+seeZKAsH=d_LpVEVRfafnvqDmj3czFf1daOTbXVyw@mail.gmail.com>
<CAA5RZ0t2vArQ3EpWSqSQekROuKeaonvgOz=Czkp4Q0tS_krscQ@mail.gmail.com>
<CAA5RZ0sw8ZuAYt+bJ_VvJvcHVKe+=1tstC7oqAqUye9_3Ta6gg@mail.gmail.com>
<CALj2ACXhLVJh0OeN5W61_UvhyBxH3k98ffXhnRPYr8NsNbMZSw@mail.gmail.com>
<an6P_WQNCM4P843q@paquier.xyz>
<CAA5RZ0tbkiEpD0ZBL+ACKO8o5mDkZmZq0PAdABqQt2nNr8MKjQ@mail.gmail.com>
<CALj2ACWWf-zDXpXDZf5fscPq_fwVY=NX+7w4JcObcgXuY9=h+Q@mail.gmail.com>
<aoeJa9Ap4_MyFX3_@paquier.xyz>
<CALj2ACX-49BrUTXaM3HeWVaZr+zGkbcLNJcrQ_dgjYF9AtW-kg@mail.gmail.com>
<CALj2ACVYtmj=P4u1cBO+MwHFYQw_wzVxhtcV1WWrELbSOvuuzg@mail.gmail.com>
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../apkCcttASAC6d6J8@paquier.xyz/2-signature.asc)
download
view thread (32+ messages) latest in thread
Message-ID: <apkCcttASAC6d6J8@paquier.xyz>
Permalink: ../apkCcttASAC6d6J8@paquier.xyz/
Also on: postgresql.org/message-id/apkCcttASAC6d6J8@paquier.xyz
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, bharath.rupireddyforpostgres@gmail.com, samimseih@gmail.com, pgsql-hackers@lists.postgresql.org, satyanarlapuram@gmail.com
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum
In-Reply-To: <apkCcttASAC6d6J8@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox