On Wed, Feb 22, 2012 at 6:53 AM, Greg Smith g...@2ndquadrant.com wrote:
A look back on this now that I'm done with it does raise one large question
though. I added some examples of how to measure timing overhead using psql.
While I like the broken down timing data that this utility provides,
Greg Smith wrote:
Anyway, the patch does now includes several examples and a short primer on
PC clock hardware, to help guide what good results look like and why they've
been impossible to obtain in the past. That's a bit Linux-centric, but the
hardware described covers almost all systems
On 02/22/2012 11:10 AM, Jay Levitt wrote:
N.B.: Windows has at least two clock APIs, timeGetTime and
QueryPerformanceCounters (and probably more, these days). They rely on
different hardware clocks, and can get out of sync with each other;
meanwhile, QueryPerformanceCounters can get out of sync
On Wed, Feb 22, 2012 at 18:44, Greg Smith g...@2ndquadrant.com wrote:
As far as I've been able to tell, there aren't any issues unique to Windows
there. Multiple cores can have their TSC results get out of sync on Windows
for the same reason they do on Linux systems, and there's also the same
On 02/22/2012 12:25 PM, Marti Raudsepp wrote:
On Wed, Feb 22, 2012 at 18:44, Greg Smithg...@2ndquadrant.com wrote:
As far as I've been able to tell, there aren't any issues unique to Windows
there. Multiple cores can have their TSC results get out of sync on Windows
for the same reason they
On Wed, Feb 22, 2012 at 19:36, Greg Smith g...@2ndquadrant.com wrote:
From the patch:
Newer operating systems may check for the known TSC problems and
switch to a slower, more stable clock source when they are seen.
If your system supports TSC time but doesn't default to that, it
may be
