Horton

Re: Track the amount of time waiting due to cost_delay

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Masahiro Ikeda <ikedamsh@oss.nttdata.com>, "Imseih (AWS), Sami" <simseih@amazon.com>, Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2024-12-14T04:06:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add delay time to VACUUM/ANALYZE (VERBOSE) and autovacuum logs.

  2. Add cost-based vacuum delay time to progress views.

  3. Add is_analyze parameter to vacuum_delay_point().

  4. Refresh cost-based delay params more frequently in autovacuum

Attachments

I spent some time preparing v12 for commit and made the following larger
changes:

* I renamed the column to delay_time and changed it back to repoting
  milliseconds to match other stats views like pg_stat_io.

* I optimized the code in vacuum_delay_point a bit.  Notably, we're now
  just storing the nanoseconds value in the pgstat param, so we now have to
  divide by 1,000,000 in the views.

* I added a track_cost_delay_timing parameter that is off by default.  The
  new timing code is only used when this parameter is turned on.  This is
  meant to match parameters like track_io_timing.  I felt that this was
  important since this is relatively hot code.

* I also added delay_time to pg_stat_progress_analyze.  It seems to use the
  same vacuum_delay_point() function, so we actually need to do a bit of
  refactoring to make sure the right pgstat param is incremented.

I think this has been discussed in the thread a bit already, but I do think
we should consider also adding this information to the vacuum/analyze log
messages and to the output of VACUUM/ANALYZE (VERBOSE).  That needn't hold
up this patch, though.

Finally, I can't help but feel that the way we are adding this information
is a bit weird, both in how we are doing it and where we are presenting the
results.  I don't see any reason that pgstat_progress_incr_param() and
friends can't handle this information, but I don't see any existing uses
for timing information.  Plus, IMHO it's debatable whether the delay time
is really "progress" information, although I haven't thought of a better
place (existing or new) for it.

Thoughts?

-- 
nathan