Skip site navigation (1) Skip section navigation (2)

Re: pg_test_timing tool for EXPLAIN ANALYZE overhead

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, ants(dot)aasma(at)eesti(dot)ee
Subject: Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
Date: 2012-02-22 17:36:28
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 02/22/2012 12:25 PM, Marti Raudsepp wrote:
> On Wed, Feb 22, 2012 at 18:44, Greg Smith<greg(at)2ndquadrant(dot)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
>> frequency/temperature issues.
> Not on recent Linux kernel versions. Linux automatically detects when
> the TSC is unstable (due to power management or out-of-sync
> cores/sockets) and automatically falls back to the more expensive HPET
> or ACPI methods.

 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 disabled for a good reason.

I ran into a case like you're showing here in my longer exploration of 
this at 
  I stopped just short of showing what the TSC error message looked 
like.  I hoped that with the above and some examples showing dmesg | 
grep, that would be enough to lead enough people toward finding this on 
their own.

Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support

In response to


pgsql-hackers by date

Next:From: Jeroen VermeulenDate: 2012-02-22 17:54:41
Subject: Re: VACUUM ANALYZE is faster than ANALYZE?
Previous:From: Greg SmithDate: 2012-02-22 17:26:20
Subject: Re: WIP: URI connection string support for libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group