Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
От | Tom Lane |
---|---|
Тема | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken |
Дата | |
Msg-id | 709425.1678411315@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
|
Список | 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
В списке pgsql-hackers по дате отправления: