Re: Restart pg_usleep when interrupted

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: Restart pg_usleep when interrupted
Дата
Msg-id ZrvQhkrqFrLbu4kl@nathan
обсуждение исходный текст
Ответ на Re: Restart pg_usleep when interrupted  ("Imseih (AWS), Sami" <samimseih@gmail.com>)
Ответы Re: Restart pg_usleep when interrupted
Re: Restart pg_usleep when interrupted
Re: Restart pg_usleep when interrupted
Список pgsql-hackers
On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote:
>> None of this seems intractable to me.  1 Hz seems like an entirely
>> reasonable place to start, and it is very easy to change (or to even make
>> configurable).  pg_stat_progress_vacuum might show slightly old values in
>> this column, but that should be easy enough to explain in the docs if we
>> are really concerned about it.  If other callers want to do something
>> similar, maybe we should add a more generic implementation in
>> backend_progress.c.
>> 
> I don't know if I agree. Making vacuum sleep more robust to handle
> interrupts seems like a cleaner general solution than to add
> even more code to handle this case or have to explain the behavior of
> cost delay instrumentation in docs.

Another concern is the huge number of PqMsg_Progress messages sent by
parallel workers with that approach.  In Bertrand's tests, he was seeing
nearly 350K interrupts for a ~19 minute vacuum (~300 interrupts per
second).  That seems a bit extreme to me.  I don't see how anyone could
possibly need stats about vacuum delays with that level of accuracy.

-- 
nathan



В списке pgsql-hackers по дате отправления: