From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: That EXPLAIN ANALYZE patch still needs work |
Date: | 2006-06-07 21:28:21 |
Message-ID: | 17628.1149715701@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2006-06-07 at 16:56 -0400, Tom Lane wrote:
>> Certainly the removal of timing
>> is not going to convert an intolerable EXPLAIN ANALYZE runtime into an
>> acceptable one;
> I disagree, as have others.
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.
> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
> question is what we do when one is not available.
The least bad alternative I've heard is to let EXPLAIN ANALYZE print
out stats-so-far if the query is canceled by control-C or statement
timeout. The objection to this is you may mistake startup transients
for full query behavior ... but at least the numbers will be good as
far as they go.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-06-07 21:45:04 | Re: That EXPLAIN ANALYZE patch still needs work |
Previous Message | Jim C. Nasby | 2006-06-07 21:24:45 | Re: ADD/DROP INHERITS |