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: Nathan Bossart <nathandbossart@gmail.com>,
Melanie Plageman <melanieplageman@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>,
Stephen Frost <sfrost@snowman.net>
Date: 2023-03-10T01:21:55Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > OK. One idea is to provide a WaitLatchUsec(), which is just some > cross platform donkeywork that I think I know how to type in, and it > would have to round up on poll() and Windows builds. Then we could > either also provide WaitEventSetResolution() that returns 1000 or 1 > depending on availability of 1us waits so that we could round > appropriately and then track residual, but beyond that let the user > worry about inaccuracies and overheads (as mentioned in the > documentation), ... so we'd still need to have the residual-sleep-time logic? > or we could start consulting the clock and tracking > our actual sleep time and true residual over time (maybe that's what > "closed-loop control" means?). Yeah, I was hand-waving about trying to measure our actual sleep times. On reflection I doubt it's a great idea. It'll add overhead and there's still a question of whether measurement noise would accumulate. 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