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 200210160540.g9G5efA07216@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>)
List pgsql-hackers
Joe Conway wrote:
> Bruce Momjian wrote:
> > 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?
> > 
> 
> I tried two more runs of 10000, and the average is pretty steady at 0.0087. 
> However the total range is a fair bit wider than I originally reported.
> 
> I added a forth time() call to see what the effect would be. It increased the 
> average to 0.0089 (two runs of 10000 connects each), so I don't think the 
> time() call explains the entire difference.
> 
> Not sure this is worth worrying about or not. I'd guess anyone serious about 
> keeping connect time to a minimum uses some kind of connection pool or 
> persistent connection anyway.

Well, the fact you see a change of 0.0002 is significant.  Let me add
that in the old code there was only one time() call _in_ the loop, while
now, there are two, so I can easily see there are several additional
time() calls.  Did you put your calls in the while loop?

--  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: Bruce Momjian
Date:
Subject: Re: Postgresql and multithreading
Next
From: Gavin Sherry
Date:
Subject: Re: Postgresql and multithreading