Horton

Re: Track the amount of time waiting due to cost_delay

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Masahiro Ikeda <ikedamsh@oss.nttdata.com>, Nathan Bossart <nathandbossart@gmail.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-09T16:41:03Z
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

Hi,

On Mon, Dec 09, 2024 at 08:34:13PM +0530, Dilip Kumar wrote:
> On Mon, Dec 9, 2024 at 6:55 PM Bertrand Drouvot
> > Yeah. I think we could change the wording that way:
> >
> > s/waiting due to/waiting during/
> >
> > Does that make sense? I don't think we need to mention cost limit here.
> 
> Yeah that should be fine.

Thanks! Done in v10 attached. BTW, 0001 and 0002 have been merged (thanks
Masahiro-san for having confirmed that v9-0002 made sense to you too!).

> 
> I mean currently we are tracking "time_since_last_report" and
> accumulating the delayed_time in "nap_time_since_last_report" for each
> worker.  So my question was does it make sense to do this in a shared
> variable across workers so that we can reduce the number of reports to the
> leader?

I see. We've seen up-thread that the more we interrupt the leader the faster the
vacuum is (because the leader could be interrupted while waiting).

OTOH if we make use of shared variable then we'd need to add some "synchronization"
(pg_atomic_xxx) overhead. So we'd reduce the number of reports and add overhead.

So I think that it might be possible to see performance degradation in some cases
and so think it's safer to keep the "per worker" implementation.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com