Re: That EXPLAIN ANALYZE patch still needs work - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: That EXPLAIN ANALYZE patch still needs work
Date
Msg-id 1149782430.2691.131.camel@localhost.localdomain
Whole thread Raw
In response to Re: That EXPLAIN ANALYZE patch still needs work  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: That EXPLAIN ANALYZE patch still needs work
List pgsql-hackers
On Thu, 2006-06-08 at 10:27 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Wed, 2006-06-07 at 17:28 -0400, Tom Lane wrote:
> >> The overhead seems to be on the order of a couple tens of percent usually.
> >> I don't see how that makes the difference between an EXPLAIN ANALYZE you
> >> can run and one you can't.
> 
> > Well, thats not my experience and doesn't match others posted on
> > -hackers. 
> 
> > A simple test with pgbench shows the timing overhead of EXPLAIN ANALYZE
> > to be consistently above 500% (or more than +400%, depending upon how
> > you style those numbers).
> 
> I think we ought to find out why your machine is so broken.

> I'm too lazy to pull up any of my other machines right now, but this is
> generally consistent with my experience ever since EXPLAIN ANALYZE was
> written.

Great. Well it isn't consistent with mine, or others who've posted to
this list.

> So: what's your platform exactly?

FC5, Intel laptop running cvstip, new in January.

But thats irrelevant. I'm not a user, I solve others problems, as you
know. Hence my interest in a usable tool to do that.

So far we have myself, Kevin, Martijn and Luke all saying there is a
distortion or a massive overhead caused by EXPLAIN ANALYZE.
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00954.php
http://archives.postgresql.org/pgsql-patches/2006-05/msg00168.php

It's real. I won't press the point further.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: ADD/DROP INHERITS
Next
From: Tom Lane
Date:
Subject: Re: How to avoid transaction ID wrap