>> This sounds like useful information to me. > Thanks for looking at it!
The VacuumDelay is the only visibility available to gauge the cost_delay. Having this information advertised by pg_stat_progress_vacuum as is being proposed is much better. However, I also think that the "number of times" the vacuum went into delay will be needed as well. Both values will be useful to tune cost_delay and cost_limit. It may also make sense to accumulate the total_time in delay and the number of times delayed in a cumulative statistics [0] view to allow a user to trend this information overtime. I don't think this info fits in any of the existing views, i.e. pg_stat_database, so maybe a new view for cumulative vacuum stats may be needed. This is likely a separate discussion, but calling it out here. >> IIUC you'd need to get information from both pg_stat_progress_vacuum and >> pg_stat_activity in order to know what percentage of time was being spent >> in cost delay. Is that how you'd expect for this to be used in practice? > Yeah, one could use a query such as: > select p.*, now() - a.xact_start as duration from pg_stat_progress_vacuum p > JOIN pg_stat_activity a using (pid) Maybe all progress views should just expose the "beentry->st_activity_start_timestamp " to let the user know when the current operation began. Regards, Sami Imseih Amazon Web Services (AWS) [0] https://www.postgresql.org/docs/current/monitoring-stats.html
