Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>,
Stephen Frost <sfrost@snowman.net>
Date: 2023-03-09T22:02:51Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman > <melanieplageman@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. Can we fix this by making VacuumCostBalance carry the extra fractional delay, or would a separate variable be better? regards, tom lane
Commits
-
Use nanosleep() to implement pg_usleep().
- a948e49e2ef1 16.0 landed
-
Update obsolete comment about pg_usleep() accuracy.
- e4da2a44c17a 16.0 landed
-
Fix fractional vacuum_cost_delay.
- 2bef57ee8b38 14.8 landed
- d9c9c43af5c8 15.3 landed
- 720de00af49d 16.0 landed