Re: Help with tuning this query (with explain analyze finally)

Tom Lane wrote:

>"Ken Egervari" <ken(at)upfactor(dot)com> writes:
>
>
>>Okay, here is the explain analyze I managed to get from work.
>>
>>
>
>What platform is this on? It seems very strange/fishy that all the
>actual-time values are exact integral milliseconds.
>
>
>
I always get round milliseconds on running. In fact, I think I've seen
cases where it was actually rounding to 15/16ms. Which is the resolution
of the "clock()" call (IIRC).

This is the function I have for returning time better than clock(), but
it looks like it is still stuck no better than 1ms.
/*
* MSVC has a function called _ftime64, which is in
* "sys/timeb.h", which should be accurate to milliseconds
*/

#include <sys/types.h>
#include <sys/timeb.h>

double mf::getTime()
{
struct __timeb64 timeNow;
_ftime64(&timeNow);
return timeNow.time + timeNow.millitm / 1000.0;
}

I did, however, find this page:
http://www.wideman-one.com/gw/tech/dataacq/wintiming.htm

Which talks about the high performance counter, which is supposed to be
able to get better than 1us resolution.

GetSystemTimes() returns the idle/kernel/user times, and seems to have a
resolution of about 100ns (.1us) GetLocalTime()/GetSystemTime() only has
a resolution of milliseconds.

In my simple test, I was actually getting timings with a resolution of
.3us for the QueryPerformanceCounter(). That was the overhead of just
the call, since it was called either in a bare loop, or just one after
the other.

So probably we just need to switch to QueryPerformanceCounter()
[/Frequency].

John
=:->