From: | Jay Levitt <jay(dot)levitt(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
Cc: | 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 16:10:38 |
Message-ID: | 4F45137E.5040708@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 using Intel or AMD processors.
> Only difference with most other operating systems is how aggressively they
> have adopted newer timer hardware. At least this gives a way to measure all
> of them.
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 with itself on
(older?) multi-CPU boards.
So if you're doing high-res timing, it's good to make sure you aren't
relying on two different clocks in different places... I ran into this with
MIDI drivers years ago; and wrote a doc:
http://www.ultimatemetal.com/forum/equipment/315910-midi-latency-problem-nuendo.html#post6315034
and a clock-testing utility:
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-02-22 16:14:34 | Re: leakproof |
Previous Message | Magnus Hagander | 2012-02-22 16:02:39 | Re: pg_basebackup -x stream from the standby gets stuck |