Hi, On Mon, Jun 10, 2024 at 3:05 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > Hi hackers, > > During the last pgconf.dev I attended Robert’s presentation about autovacuum > and > it made me remember of an idea I had some time ago: $SUBJECT > > Please find attached a patch doing so by adding a new field (aka > "time_delayed") > to the pg_stat_progress_vacuum view. > > Currently one can change [autovacuum_]vacuum_cost_delay and > [auto vacuum]vacuum_cost_limit but has no reliable way to measure the impact > of > the changes on the vacuum duration: one could observe the vacuum duration > variation but the correlation to the changes is not accurate (as many others > factors could impact the vacuum duration (load on the system, i/o > latency,...)). > > This new field reports the time that the vacuum has to sleep due to cost > delay: > it could be useful to 1) measure the impact of the current cost_delay and > cost_limit settings and 2) when experimenting new values (and then help for > decision making for those parameters). > > The patch is relatively small thanks to the work that has been done in > f1889729dd (to allow parallel worker to report to the leader).
Thank you for the proposal and the patch. I understand the motivation of this patch. Beside the point Nathan mentioned, I'm slightly worried that massive parallel messages could be sent to the leader process when the cost_limit value is low. FWIW when I want to confirm the vacuum delay effect, I often use the information from the DEBUG2 log message in VacuumUpdateCosts() function. Exposing these data (per-worker dobalance, cost_lmit, cost_delay, active, and failsafe) somewhere in a view might also be helpful for users for checking vacuum delay effects. It doesn't mean to measure the impact of the changes on the vacuum duration, though. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com