From: | "Imseih (AWS), Sami" <samimseih(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Restart pg_usleep when interrupted |
Date: | 2024-08-13 16:07:46 |
Message-ID: | ac329991-7cfa-4006-b155-97ba19c5705d@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/13/24 10:57 AM, Nathan Bossart wrote:
> 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
Perhaps "complex" may not be the correct way to describe it.
Having to add special handling to space out instrumentation
directly in vacuum_delay_point seems very odd to me. I don't
think vacuum_delay_point should have to worry about this.
Also,
1/ what is an appropriate interval to collect these stats?
2/ What if there are other callers in the future that wish
to instrument parallel vacuum workers? they will need to implement
similar logic.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Imseih (AWS), Sami | 2024-08-13 16:15:56 | Re: Restart pg_usleep when interrupted |
Previous Message | Nathan Bossart | 2024-08-13 15:57:24 | Re: Restart pg_usleep when interrupted |