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: Bertrand Drouvot <bertranddrouvot.pg@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-10T04:47:02Z
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 Mon, Dec 9, 2024 at 10:11 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> 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.

Okay, that makes sense.  Thanks.

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