Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Date
Msg-id 200210160523.g9G5NiS05055@candle.pha.pa.us
Whole thread Raw
In response to Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c  (Joe Conway <mail@joeconway.com>)
Responses Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
List pgsql-hackers
Joe Conway wrote:
> Seems to work well. But one slight concern:
> 
> with previous 2 line patch
> --------------------------
> good connect info, using hostaddr, timeout = 1 || 2 second(s)
> =============================================================
> unsuccessful 0 times: avg n/a
> successful 20000 times: avg 0.0074
> 
> These tests were on the same, otherwise unloaded development box. Not sure if 
> it is an artifact or not, but the average connection time has gone from 0.0074 
> to 0.0087, an increase of about 17%. Also worth noting is that there was very 
> little deviation from connect-to-connect on both of the tests (eye-balled the 
> total range at about 0.0003). I did not bother calculating standard deviation 
> of the connect times, but I'm certain it would not be enough to account for 
> the difference. Could anything in Bruce's patch account for this, or do you 
> think it is normal variation due to something on my dev box?

Yes, the new code has _three_ time() calls, rather than the old code
that I think only had two.  I was going to mention it but I figured
time() was a pretty light system call, sort of like getpid().

I needed the additional time() calls so the computation of remaining
time was more accurate, i.e. we are not resetting the timer on a
select() EINTR anymore.

Should I try to rework it?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Anuradha Ratnaweera
Date:
Subject: Re: Postgresql and multithreading
Next
From: Gavin Sherry
Date:
Subject: Re: Postgresql and multithreading