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

From Sami Imseih
Subject Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Date
Msg-id CAA5RZ0vV_+NwqCjvkgz8MzxOy15MeqFTmR19GbYcCGEeQ2M81g@mail.gmail.com
Whole thread
In response to Report index currently being vacuumed in pg_stat_progress_vacuum  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: [RFC PATCH v0 0/7] Add EXPLAIN ANALYZE wait event reporting
List pgsql-hackers
In short, I tend to agree with having one row per worker in the vacuum
progress report, joining pg_stat_activity's leader_pid for simpler
usability, extensibility, and less information bloat, along with doc
changes to explain this. One concern is that some progress fields
would be null on worker rows, but documenting this should be
sufficient. I could be missing something here, so I would like to hear
some thoughts before coming up with a patch.

I will look at the rest of the points later in detail, but it does sound like to me that a new worker view will be a better place to hold extra per worker ( or leader ) details and the current view will remain high level/progress data. Unused progress fields do not sound right to me, and I also worry we will bloat the existing view over time if we want to add more per worker fields. 

--
Sami



pgsql-hackers by date:

Previous
From: Andrey Rachitskiy
Date:
Subject: Re: Residual cleanups for tied objects in PL/Perl
Next
From: Alexander Lakhin
Date:
Subject: Test tidscan,sql is not immune to autovacuum in v14