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

Re: [PERFORM] Help with tuning this query (with explain analyze finally)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ken Egervari" <ken(at)upfactor(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [PERFORM] Help with tuning this query (with explain analyze finally)
Date: 2005-03-02 22:29:48
Message-ID: 14444.1109802588@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-performance
"Ken Egervari" <ken(at)upfactor(dot)com> writes:
>> What platform is this on?  It seems very strange/fishy that all the
>> actual-time values are exact integral milliseconds.

> My machine is WinXP professional, athon xp 2100, but I get similar results 
> on my Intel P4 3.0Ghz as well (which is also running WinXP).  Why do you 
> ask? 

Well, what it suggests is that gettimeofday() is only returning a result
good to the nearest millisecond.  (Win32 hackers, does that sound right?)

If so, I'd have to take the EXPLAIN ANALYZE results with a big grain of
salt, because what it's trying to do is add up a lot of
mostly-sub-millisecond intervals.  What would essentially happen is that
whichever plan node had control at a particular millisecond boundary
would get charged for the whole preceding millisecond, and any other
nodes (which might have actually eaten most of the millisecond) would
get charged nothing.

Over a sufficiently long query run, the errors would average out, but
this wasn't that long --- 312 milliseconds, so in essence we are trying
to estimate the query's behavior from only 312 samples of where it was
at the millisecond boundaries.  I don't trust profiles based on less
than a few thousand samples ...

Most modern machines seem to have clocks that can count elapsed time
down to near the microsecond level.  Anyone know if it's possible to get
such numbers out of Windows, or are we stuck with milliseconds?

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Dave HeldDate: 2005-03-02 23:01:14
Subject: Re: [PERFORM] Help with tuning this query (with explain analyze finally)
Previous:From: Ken EgervariDate: 2005-03-02 20:38:16
Subject: Re: Help with tuning this query (with explain analyze finally)

pgsql-hackers-win32 by date

Next:From: Dave HeldDate: 2005-03-02 23:01:14
Subject: Re: [PERFORM] Help with tuning this query (with explain analyze finally)
Previous:From: pgsqlDate: 2005-03-02 21:38:28
Subject: Re: [pgsql-hackers-win32] snprintf causes regression

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