Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken

On Fri, Mar 10, 2023 at 2:21 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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?

Ah, perhaps not. Considering that the historical behaviour on the
main affected platform (Windows) was already to round up to
milliseconds before we latchified this code anyway, and now a google
search is telling me that the relevant timer might in fact be *super*
lumpy, perhaps even to the point of 1/64th of a second[1] (maybe
that's a problem for a Windows hacker to look into some time; I really
should create a wiki page of known Windows problems in search of a
hacker)... it now looks like sub-ms residual logic would be a bit
pointless after all.

I'll go and see about usec latch waits. More soon.

[1] https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/