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 по дате отправления: