X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D957F9FA2E6 for ; Tue, 6 Jun 2006 12:21:35 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 10531-09 for ; Tue, 6 Jun 2006 12:21:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from hs5.cfa.cmu.edu (HS5.CFA.cmu.edu [128.2.103.215]) by postgresql.org (Postfix) with ESMTP id C89F29F9316 for ; Tue, 6 Jun 2006 12:21:17 -0300 (ADT) Received: from webmail.webopticon.org (hs5.cfa.cmu.edu [127.0.0.1]) by hs5.cfa.cmu.edu (8.12.11.20060308/8.12.11) with ESMTP id k56FLFcX026886 for ; Tue, 6 Jun 2006 11:21:15 -0400 Received: from 216.41.12.254 (SquirrelMail authenticated user agentm) by webmail.webopticon.org with HTTP; Tue, 6 Jun 2006 11:21:15 -0400 (EDT) Message-ID: <47764.216.41.12.254.1149607275.squirrel@webmail.webopticon.org> In-Reply-To: <1149604741.2621.487.camel@localhost.localdomain> References: <1149534308.3583.56.camel@bg002441.pro-unlimited.com> <22706.1149538039@sss.pgh.pa.us> <20060605203851.GB7071@phlogiston.dyndns.org> <23915.1149541591@sss.pgh.pa.us> <1149604741.2621.487.camel@localhost.localdomain> Date: Tue, 6 Jun 2006 11:21:15 -0400 (EDT) Subject: Re: Some queries starting to hang From: "A.M." To: pgsql-performance@postgresql.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/58 X-Sequence-Number: 19415 Explain analyze could at least put an asterisk around actual time that deviated by some factor from the estimated time. On Tue, June 6, 2006 10:39 am, Simon Riggs wrote: > > This is a good example of a case where the inefficiency of EXPLAIN > ANALYZE would be a contributory factor to it not actually being > available for diagnosing a problem. > > Maybe we need something even more drastic than recent proposed changes > to EXPLAIN ANALYZE? > > Perhaps we could annotate the query tree with individual limits. That > way a node that was expecting to deal with 1 row would simply stop > executing the EXPLAIN ANALYZE when it hit N times as many rows (default=no > limit). That way, we would still be able to see a bad plan even without > waiting for the whole query to execute - just stop at a point where the > plan is far enough off track. That would give us what we need: pinpoint > exactly which part of the plan is off-track and see how far off track it > is. If the limits were configurable, we'd be able to opt for > faster-but-less-accurate or slower-yet-100% accuracy behaviour. We > wouldn't need to worry about timing overhead either then. > > e.g. EXPLAIN ANALYZE ERRLIMIT 10 SELECT ... > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > >