On Thu, Mar 9, 2023 at 5:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.mu...@gmail.com> writes: > > On Fri, Mar 10, 2023 at 11:02 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> The caf626b2c code would only work well on platforms that have > >> microsecond-based sleep primitives, so it was already not too portable. > > > Also, the previous coding was already b0rked, because pg_usleep() > > rounds up to milliseconds on Windows (with a surprising formula for > > rounding), and also the whole concept seems to assume things about > > schedulers that aren't really universally true. If we actually cared > > about high res times maybe we should be using nanosleep and tracking > > the drift? And spreading it out a bit. But I don't know. > > Yeah, I was wondering about trying to make it a closed-loop control, > but I think that'd be huge overkill considering what the mechanism is > trying to accomplish. > > A minimalistic fix could be as attached. I'm not sure if it's worth > making the state variable global so that it can be reset to zero in > the places where we zero out VacuumCostBalance etc. Also note that > this is ignoring the VacuumSharedCostBalance stuff, so you'd possibly > have the extra delay accumulating in unexpected places when there are > multiple workers. But I really doubt it's worth worrying about that.
What if someone resets the delay guc and there is still a large residual?