Re: Where does the time go? - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Where does the time go?
Date
Msg-id 20060325152405.GC1695@svana.org
Whole thread Raw
In response to Re: Where does the time go?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Where does the time go?  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Where does the time go?  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Sat, Mar 25, 2006 at 10:00:51AM -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I would like to implement an additional mode for EXPLAIN ANALYZE that
> > does no timing instrumentation at all. Most of the time just looking for
> > differences between estimated and actual row counts is all you need.
>
> I don't really agree with that premise ... without timings, you cannot
> for instance tell if the planner has over/underestimated the cost of an
> index fetch.

I agree. However, if it's the overhead of calling gettimeofday() that
slows everything down, perhaps we should tackle that end. For example,
have a sampling mode that only times say 5% of the executed nodes.

EXPLAIN ANALYZE SAMPLE blah;

And then in InstrStart have a quick test that skips the gettimeofday
for this interation sometimes. You'd probably need some heuristics
because you always want to catch the first iteration but after the
10,000th tuple in an indexscan, you're probably not going to learn
anything new.

You could do a non-random sampling fairly easily:

if( ntuples < 16 )  yes
else if( ntuples < 16*16 && (ntuples%16) == 0)  yes
else if( ntuples < 16*16*16 && ntuples%(16*16) == 0)  yes
else   etc etc etc

This mean that the more often a node is executed, the less often you
actually time it. Note, we store ntuples as a doulbe so the mod
operation won't work...

How does this sound?
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Domains as Subtypes
Next
From: "Andrew Dunstan"
Date:
Subject: Re: [SUGGESTION] CVSync