Re: Restart pg_usleep when interrupted
От | Imseih (AWS), Sami |
---|---|
Тема | Re: Restart pg_usleep when interrupted |
Дата | |
Msg-id | 90ec1618-58db-46b3-8c9b-13616ac839a7@gmail.com обсуждение исходный текст |
Ответ на | Re: Restart pg_usleep when interrupted (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Restart pg_usleep when interrupted
|
Список | pgsql-hackers |
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. On the other hand, with allowing the sleep to deal with interrupts,no additional logic to space out instrumentation is required. Regards, Sami [0] https://commitfest.postgresql.org/49/5027/
В списке pgsql-hackers по дате отправления: