Re: Track the amount of time waiting due to cost_delay

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