Horton

Re: Track the amount of time waiting due to cost_delay

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@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-11T06:43:06Z
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 Tue, Dec 10, 2024 at 11:25 PM Nathan Bossart
<nathandbossart@gmail.com> wrote:
>
> On Mon, Dec 09, 2024 at 04:41:03PM +0000, Bertrand Drouvot wrote:
> > +       <structfield>time_delayed</structfield> <type>bigint</type>
>
> I think it's also worth considering names like total_delay and
> cumulative_delay.

+1, I vote for total_delay

> > +       Total amount of time spent in milliseconds waiting during <xref linkend="guc-vacuum-cost-delay"/>
> > +       or <xref linkend="guc-autovacuum-vacuum-cost-delay"/>. In case of parallel
> > +       vacuum the reported time is across all the workers and the leader. The
> > +       workers update the column no more frequently than once per second, so it
> > +       could show slightly old values.
>
> 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.  I might also
> suggest some changes to the description:
>
>         Total accumulated time spent sleeping due to the cost-based vacuum
>         delay settings (e.g., vacuum_cost_delay, vacuum_cost_limit).  This
>         includes the time that any associated parallel workers have slept, too.
>         However, parallel workers report their sleep time no more frequently
>         than once per second, so the reported value may be slightly stale.
>

This description looks good.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com