Message-ID: <ac329991-7cfa-4006-b155-97ba19c5705d@gmail.com>
Date: Tue, 13 Aug 2024 11:07:46 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Restart pg_usleep when interrupted
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
 Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Tom Lane
 <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <AED4B8D0-3ED1-463C-BA9F-BFF4B511315E@gmail.com>
 <BB742B52-D481-4D5A-926A-4ED4A6ADA98B@gmail.com>
 <ZrowomFX5yMV9zUm@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZrpnfTVK-iaIW98I@nathan> <e3297b5e-0b33-4f45-afcd-4b00ba0b3547@gmail.com>
 <cb18c6a7-4394-4488-ad71-0b9826c8899c@iki.fi> <ZrqG0tIgP2HbGRm1@nathan>
 <2b5ac681-11d5-470d-af40-89ead9a868aa@gmail.com> <Zrt3ReA-nB7MJn2q@nathan>
 <90ec1618-58db-46b3-8c9b-13616ac839a7@gmail.com> <ZruCZOKzS0LGAGTb@nathan>
Content-Language: en-US
From: "Imseih (AWS), Sami" <samimseih@gmail.com>
In-Reply-To: <ZruCZOKzS0LGAGTb@nathan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/ac329991-7cfa-4006-b155-97ba19c5705d%40gmail.com>
Precedence: bulk


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