Re: [pgsql-hackers-win32] Help with tuning this query (with - Mailing list pgsql-performance

From John A Meinel
Subject Re: [pgsql-hackers-win32] Help with tuning this query (with
Date
Msg-id 422D2B7D.5080702@arbash-meinel.com
Whole thread Raw
In response to Re: [pgsql-hackers-win32] Help with tuning this query (with  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:

>John A Meinel <john@arbash-meinel.com> writes:
>
>
>>Dave Held wrote:
>>
>>
>>>There is always clock().
>>>
>>>
>
>
>
>>My experience with clock() on win32 is that CLOCKS_PER_SEC was 1000, and
>>it had a resolution of 55clocks / s. When I just did this:
>>
>>
>
>The other problem is it measures process CPU time, not elapsed time
>which is probably more significant for our purposes.
>
>Which brings up a question: just what does QueryPerformanceCounter
>measure?
>
>            regards, tom lane
>
>
clock() according to the Visual Studio Help measures wall clock time.
But you're right, POSIX says it is approximation of processor time.

The docs don't say specifically what QueryPerformanceCounter() measures,
but states

> The *QueryPerformanceCounter* function retrieves the current value of
> the high-resolution performance counter.
>
It also states:

>
>         Remarks
>
> On a multiprocessor machine, it should not matter which processor is
> called. However, you can get different results on different processors
> due to bugs in the BIOS or the HAL. To specify processor affinity for
> a thread, use the *SetThreadAffinityMask* function.
>

So it sounds like it is actually querying some counter independent of
processing.

In fact, there is also this statement:

> *QueryPerformanceFrequency*
>
> The QueryPerformanceFrequency function retrieves the frequency of the
> high-resolution performance counter, if one exists. The frequency
> cannot change while the system is running.
>
If that is accurate, it would make QueryPerformanceCounter independent
of things like speed stepping, etc. So again, it sounds independent of
processing.

John
=:->


Attachment

pgsql-performance by date:

Previous
From: "Michael Zoephel"
Date:
Subject: performance problems
Next
From: John A Meinel
Date:
Subject: Re: adding 'limit' leads to very slow query