Re: Restart pg_usleep when interrupted - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Restart pg_usleep when interrupted
Date
Msg-id ZsNW5eLjYtIuNZAo@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Restart pg_usleep when interrupted  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
Hi,

On Thu, Aug 15, 2024 at 04:13:29PM -0500, Nathan Bossart wrote:
> On Wed, Aug 14, 2024 at 06:00:06AM +0000, Bertrand Drouvot wrote:
> > I gave it more thoughts and I don't think we have to choose between the two.
> > The 1 Hz approach reduces the number of interrupts and Sami's patch provides a
> > way to get "accurate" delay in case of interrupts. I think both have their own
> > benefit. 
> 
> Is it really that important to delay with that level of accuracy?  In most
> cases, the chances of actually interrupting a given vacuum delay point are
> pretty small.  Even in the extreme scenario you tested with ~350K
> interrupts in a 19 minute vacuum, you only saw a 10-15% difference in total
> time.  I wouldn't say I'm diametrically opposed to this patch, but I do
> think we need to carefully consider whether it's worth the extra code.
>

I'm not 100% sure that it is worth it but on OTOH I'm thinking that could be the
case for someone that cares enough to change the cost delay from say 2ms to 3ms.

I mean, given the granularity we expose in the cost delay, one could expect to
get "accurate" delay. The doc is cautious enough to mention that "such delays may
not be measured accurately on older platforms" which makes me think that could
be worth to implement it.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: gitmaster server problem?
Next
From: Dave Page
Date:
Subject: Re: gitmaster server problem?