| From: | Marti Raudsepp <marti(at)juffo(dot)org> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| 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:25:24 |
| Message-ID: | CABRT9RDAYnK87Z=pxaSEzYJPZhz95cKEOzZ6W22wYbH2pU5Rew@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
e.g:
% dmesg |grep -i tsc
[ 0.000000] Fast TSC calibration using PIT
[ 0.164075] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[ 0.197062] Switching to clocksource tsc
[ 0.260960] Marking TSC unstable due to TSC halts in idle
Whether these tests cover 100% of the possible conditions, and whether
the detection has race conditions or not, I don't know.
Regards,
Marti
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2012-02-22 17:26:20 | Re: WIP: URI connection string support for libpq |
| Previous Message | Noah Misch | 2012-02-22 17:00:07 | Re: foreign key locks, 2nd attempt |