On Mon, Dec 9, 2024 at 10:11 PM Bertrand Drouvot <bertranddrouvot...@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
