Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
От | Tom Lane |
---|---|
Тема | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken |
Дата | |
Msg-id | 620014.1678399371@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: > 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
В списке pgsql-hackers по дате отправления: