Re: Track the amount of time waiting due to cost_delay - Mailing list pgsql-hackers

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