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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32 pgsql-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

Browse pgsql-hackers-win32 by date

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

Browse pgsql-performance by date

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