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-11T16:40:04Z
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

On Wed, Dec 11, 2024 at 07:00:50AM +0000, Bertrand Drouvot wrote:
> On Tue, Dec 10, 2024 at 11:55:41AM -0600, Nathan Bossart wrote:
>> I wonder if it makes sense to provide this value as an interval instead of
>> the number of milliseconds to make it more human-readable. 
> 
> Yeah we could do so, but that would mean:
> 
> 1. Write a dedicated "pg_stat_get_progress_info()" function for VACUUM. Indeed,
> the current pg_stat_get_progress_info() is shared across multiple "commands" and
> then we wouldn't be able to change it's output types in pg_proc.dat.
> 
> Or
> 
> 2. Make use of make_interval() in the pg_stat_progress_vacuum view creation.
> 
> I don't like 1. that much and given that that would be as simple as: 
> 
> "
> select make_interval(secs => time_delayed / 1000) from pg_stat_progress_vacuum; 
> "
> 
> for an end user to display an interval, I'm not sure we should provide an interval
> by default.
> 
> That said, I agree that milliseconds is not really human-readable and
> does not provide that much added value (except flexibility), so I'd vote for 2.
> if you feel we should provide an interval by default.

That's roughly what I had in mind.

> Yeah I like it, thanks! Now, I'm wondering if we should not also add something
> like this:
> 
> "
> Since multiple workers can sleep simultaneously, the total sleep time can exceed
> the actual duration of the vacuum operation.
> "
> 
> As that could be surprising to see this behavior in action.

I'd vote for leaving that out, if for no other reason than it can be
deduced from the rest of the description.

-- 
nathan