"Ken Egervari" <[EMAIL PROTECTED]> writes:
>> 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
Well, what it suggests is that gettimeofday() is only returning a result
good to the nearest millisecond. (Win32 hackers, does that sound right?)
If so, I'd have to take the EXPLAIN ANALYZE results with a big grain of
salt, because what it's trying to do is add up a lot of
mostly-sub-millisecond intervals. What would essentially happen is that
whichever plan node had control at a particular millisecond boundary
would get charged for the whole preceding millisecond, and any other
nodes (which might have actually eaten most of the millisecond) would
get charged nothing.
Over a sufficiently long query run, the errors would average out, but
this wasn't that long --- 312 milliseconds, so in essence we are trying
to estimate the query's behavior from only 312 samples of where it was
at the millisecond boundaries. I don't trust profiles based on less
than a few thousand samples ...
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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match