Re: Restart pg_usleep when interrupted
От | Nathan Bossart |
---|---|
Тема | Re: Restart pg_usleep when interrupted |
Дата | |
Msg-id | ZruCZOKzS0LGAGTb@nathan обсуждение исходный текст |
Ответ на | Re: Restart pg_usleep when interrupted ("Imseih (AWS), Sami" <samimseih@gmail.com>) |
Ответы |
Re: Restart pg_usleep when interrupted
|
Список | pgsql-hackers |
On Tue, Aug 13, 2024 at 10:47:51AM -0500, Imseih (AWS), Sami wrote: > On 8/13/24 10:09 AM, Nathan Bossart wrote: >> On Mon, Aug 12, 2024 at 05:35:08PM -0500, Imseih (AWS), Sami wrote: >> > > Skimming the last few messages of that thread [0], it looks like Bertrand >> > > is exploring ways to avoid so many interrupts. I guess the unavoidable >> > > question is whether this work is still worthwhile given that improvement. >> > The way the instrumentation in [0] dealt with interrupts was too complex, >> > which is why it seemed better to handle the restart the remainder of the >> > sleep in the sleep function >> Can you elaborate on how it is too complex? >> > [0] made vacuum_delay_point more complex as it has to > instrument cost_delay at an interval to reduce the number > of interrupts to the leader. Sure, but looking at the patch [0], it adds maybe an extra 10 lines of code to limit the reports to 1 Hz. That doesn't strike me as too complex... [0] https://postgr.es/m/ZnlPZZZJCRu/8fka%40ip-10-97-1-34.eu-west-3.compute.internal -- nathan
В списке pgsql-hackers по дате отправления: