> >> What platform is this on? It seems very strange/fishy
> that all the
> >> actual-time values are exact integral milliseconds.
>
> > My machine is WinXP professional, athon xp 2100, but I get similar
> > results on my Intel P4 3.0Ghz as well (which is also
> running WinXP).
> > Why do you ask?
>
> Well, what it suggests is that gettimeofday() is only
> returning a result good to the nearest millisecond. (Win32
> hackers, does that sound right?)
Yes. The gettimeofday() implementation (in
src/backend/port/gettimeofday.c).
Actually, in reality you don't even get millisecond resolution it seems
(after some reading up). More along the line of
10-millisecond-resolution.
See for example
http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionTimer/.
> Most modern machines seem to have clocks that can count
> elapsed time down to near the microsecond level. Anyone know
> if it's possible to get such numbers out of Windows, or are
> we stuck with milliseconds?
There are, see link above. But it's definitly not easy. I don't think we
can just take the complete code from their exmaple (due to licensing).
We could go with the "middle way", but it has a couple of pitfalls.
Do we need actual high precision time, or do we just need to be able to
get high precision differences? Getting the differences is fairly easy,
but if you need to "sync up" any drif then it becomes a bit more
difficult.
//Magnus
