Re: pg_test_timing tool for EXPLAIN ANALYZE overhead - Mailing list pgsql-hackers

From Jay Levitt
Subject Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
Date
Msg-id 4F45137E.5040708@gmail.com
Whole thread Raw
In response to pg_test_timing tool for EXPLAIN ANALYZE overhead  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: pg_test_timing tool for EXPLAIN ANALYZE overhead  (Greg Smith <greg@2ndQuadrant.com>)
List 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:

https://github.com/jaylevitt/miditime



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_basebackup -x stream from the standby gets stuck
Next
From: "Kevin Grittner"
Date:
Subject: Re: leakproof