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 34B539FA2E6 for ; Tue, 6 Jun 2006 12:38:10 -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 20321-02 for ; Tue, 6 Jun 2006 12:38:00 -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 9FE8C9F9316 for ; Tue, 6 Jun 2006 12:38:00 -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 k56FbwUC026960 for ; Tue, 6 Jun 2006 11:37:58 -0400 Received: from 216.41.12.254 (SquirrelMail authenticated user agentm) by webmail.webopticon.org with HTTP; Tue, 6 Jun 2006 11:37:58 -0400 (EDT) Message-ID: <44027.216.41.12.254.1149608278.squirrel@webmail.webopticon.org> In-Reply-To: <20060606152949.GB10018@phlogiston.dyndns.org> 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> <17148.1149605005@sss.pgh.pa.us> <1149605576.2621.502.camel@localhost.localdomain> <17426.1149606369@sss.pgh.pa.us> <20060606152949.GB10018@phlogiston.dyndns.org> Date: Tue, 6 Jun 2006 11:37:58 -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/60 X-Sequence-Number: 19417 Hmmm...It could generate NOTICEs whenever there is a drastic difference in rowcount or actual time... On Tue, June 6, 2006 11:29 am, Andrew Sullivan wrote: > On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote: > >>> it was properly instrumented. That way, the OP might have been able >>> to discover the root cause himself... >> >> I don't think that helps, as it just replaces one uncertainty by >> another: how far did the EXPLAIN really get towards completion of the >> plan? You still don't have any hard data. > > Well, you _might_ get something useful, if you're trying to work on a > maladjusted production system, because you get to the part that trips the > limit, and then you know, "Well, I gotta fix it that far, anyway." > > Often, when you're in real trouble, you can't or don't wait for the > full plan to come back from EXPLAIN ANALYSE, because a manager is helpfully > standing over your shoulder asking whether you're there yet. Being able > to say, "Aha, we have the first symptom," might be helpful to users. > Because the impatient simply won't wait for the > full report to come back, and therefore they'll end up flying blind > instead. (Note that "the impatient" is not always the person logged in > and executing the commands.) > > A > > > -- > Andrew Sullivan | ajs@crankycanuck.ca > I remember when computers were frustrating because they *did* exactly what > you told them to. That actually seems sort of quaint now. --J.D. Baldwin > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > > http://archives.postgresql.org > >