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

Re: Incorrect Total runtime Reported by Explain Analyze!?

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Richard Huxton <dev(at)archonet(dot)com>, Jozsef Szalay <jszalay(at)storediq(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Incorrect Total runtime Reported by Explain Analyze!?
Date: 2006-01-26 17:59:49
Message-ID: 1138298389.22740.11.camel@state.g2switchworks.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 2006-01-26 at 11:57, Michael Fuhr wrote:
> On Thu, Jan 26, 2006 at 04:49:59PM +0000, Richard Huxton wrote:
> > Jozsef Szalay wrote:
> > >I have seen it on occasion that the total runtime reported by explain
> > >analyze was much higher than the actual time the query needed to
> > >complete. The differences in my case ranged between 20-120 seconds. I'm
> > >just curious if anyone else has experienced this and whether there is
> > >something that I can do to convince explain analyze to report the
> > >execution time of the query itself rather than the time of its own
> > >execution. Engine version is 8.1.1.
> > 
> > I think it's down to all the gettime() calls that have to be made to 
> > measure how long each stage of the query takes. In some cases these can 
> > take a substantial part of the overall query time.
> 
> Another possibility is that the total query time was indeed that
> long because the query was blocked waiting for a lock.  For example:

Could be, but I've had this happen where the query returned in like 1
second but reported 30 seconds run time.

In response to

pgsql-performance by date

Next:From: Jozsef SzalayDate: 2006-01-26 18:03:36
Subject: Re: Incorrect Total runtime Reported by Explain Analyze!?
Previous:From: Michael FuhrDate: 2006-01-26 17:57:23
Subject: Re: Incorrect Total runtime Reported by Explain Analyze!?

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