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  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Add pg_walinspect function with block info columns
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add pg_walinspect function with block info columns