Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 516F91336DB6
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 19 Oct 2010 11:25:44 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 34730-06
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 19 Oct 2010 14:25:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id BA27913364DE
	for <pgsql-performance@postgresql.org>;
	Tue, 19 Oct 2010 11:25:35 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o9JEPYlY009955;
	Tue, 19 Oct 2010 10:25:34 -0400 (EDT)
To: Eric Comeau <ecomeau@signiant.com>
cc: pgsql-performance@postgresql.org, mladen.gogala@vmsinfo.com,
	Kathryn Smith <Kathryn.Smith@signiant.com>
Subject: Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE:
	COMMIT]
In-reply-to: <4CBD7FCD.3070302@signiant.com> 
References: <i9c60b$ifv$1@news.hub.org> <18890.1287411233@sss.pgh.pa.us>
	<4CBC58CD.9010906@vmsinfo.com> <19782.1287414135@sss.pgh.pa.us>
	<4CBD7FCD.3070302@signiant.com>
Comments: In-reply-to Eric Comeau <ecomeau@signiant.com>
	message dated "Tue, 19 Oct 2010 07:23:57 -0400"
Date: Tue, 19 Oct 2010 10:25:34 -0400
Message-ID: <9954.1287498334@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201010/306
X-Sequence-Number: 40724

Eric Comeau <ecomeau@signiant.com> writes:
> Okay - I'm starting to see other stmts other than just commits taking 
> longer than 5 secs sometimes as well now - stress test has been running 
> for 3 days now...some commits 17 and 15 secs ouch...

If it's not just commits then some of the stranger theories go away.
I think you're almost certainly looking at overstressed disk.

It'd be worth your while to turn on checkpoint logging and see if
the slow operations occur during checkpoints.  If so, you might be
able to ameliorate things by tweaking the checkpoint parameters
to spread out checkpoint I/O load some more.  But the bottom line
here is that you haven't got much headroom between your application's
needs and the max throughput available from your disk.  Better disk
hardware will be the only real cure.

			regards, tom lane