On Thu, Mar 9, 2023 at 5:10 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Fri, Mar 10, 2023 at 11:02 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.mu...@gmail.com> writes: > > > On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman > > > <melanieplage...@gmail.com> wrote: > > >> I think that 4753ef37e0ed undid the work caf626b2c did to support > > >> sub-millisecond delays for vacuum and autovacuum. > > > > > Given that some of the clunkier underlying kernel primitives have > > > milliseconds in their interface, I don't think it would be possible to > > > make a usec-based variant of WaitEventSetWait() that works everywhere. > > > Could it possibly make sense to do something that accumulates the > > > error, so if you're using 0.5 then every second vacuum_delay_point() > > > waits for 1ms? > > > > Yeah ... using float math there was cute, but it'd only get us so far. > > 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. > > > Can we fix this by making VacuumCostBalance carry the extra fractional > > delay, or would a separate variable be better? > > I was wondering the same thing, but not being too familiar with that > code, no opinion on that yet.
Well, that is reset to zero in vacuum() at the top -- which is called for each table for autovacuum, so it would get reset to zero between autovacuuming tables. I dunno how you feel about that... - Melanie
