Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id A92F99FB35B for ; Thu, 28 Sep 2006 14:40:33 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 63471-08 for ; Thu, 28 Sep 2006 17:40:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id B85839FB357 for ; Thu, 28 Sep 2006 14:40:29 -0300 (ADT) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 28 Sep 2006 13:40:28 -0400 id 00056444.451C090C.00005DFF Received: from Internal Mail-Server (206.210.89.202) by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 28 Sep 2006 13:38:14 -0400 Date: Thu, 28 Sep 2006 13:40:24 -0400 From: Bill Moran To: "Jim C. Nasby" Cc: Matthew Schumacher , pgsql-performance@postgresql.org Subject: Re: Problems with inconsistant query performance. Message-Id: <20060928134024.bf09db28.wmoran@collaborativefusion.com> In-Reply-To: <20060928161549.GN34238@nasby.net> References: <451AC4E2.90106@aptalaska.net> <1c9501c6e2fb$91e30200$0c67a8c0@maniek> <451BE7CD.3060807@aptalaska.net> <20060928112843.0b6e3715.wmoran@collaborativefusion.com> <20060928161549.GN34238@nasby.net> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200609/389 X-Sequence-Number: 21075 In response to "Jim C. Nasby" : > On Thu, Sep 28, 2006 at 11:28:43AM -0400, Bill Moran wrote: > > In response to Matthew Schumacher : > > > > > > What I really need is a way to profile my proc when it runs slow so that > > > I can resolve which of the queries is really slow. Anyone with an idea > > > on how to do this? > > > > You could turn on statement logging and duration logging. This would > > give you a record of when things run and how long they take. A little > > work analyzing should show you which queries are running when your > > favorite query slows down. > > By default, that doesn't help you debug what's happening inside a > function, because you only get the call to the function. I don't know if > you can increase verbosity to combat that. Right, but my point was that he believes another query is interfering when the target query is slow. Turning on those logging statements will: a) Allow him to identify times when the query is slow. b) Identify other queries that are running at the same time. If he sees a pattern (i.e. My query is always slow if query X5 is running at the same time) he'll have a good lead into further research. -- Bill Moran Collaborative Fusion Inc.