Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 090B29FB3F8 for ; Wed, 4 Oct 2006 07:59:20 -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 23821-06 for ; Wed, 4 Oct 2006 10:59:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id BAE369FB3F2 for ; Wed, 4 Oct 2006 07:59:12 -0300 (ADT) Received: by lynet.oppetid.no (Postfix, from userid 1019) id 674A611A71B; Wed, 4 Oct 2006 12:59:10 +0200 (CEST) Date: Wed, 4 Oct 2006 12:59:10 +0200 From: Tobias Brox To: Csaba Nagy Cc: Tobias Brox , postgres performance list Subject: Re: slow queue-like empty table Message-ID: <20061004105910.GE12527@oppetid.no> References: <20060928065631.GA28138@oppetid.no> <20060928073636.GG14672@oppetid.no> <1159433135.3874.204.camel@coppola.muc.ecircle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1159433135.3874.204.camel@coppola.muc.ecircle.de> Organization: Group Nordicbet User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.135 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200610/79 X-Sequence-Number: 21208 [Csaba Nagy - Thu at 10:45:35AM +0200] > So you should check for "idle in transaction" sessions, those are bad... > or any other long running transaction. Thank you (and others) for pointing this out, you certainly set us on the right track. We did have some few unclosed transactions; transactions not beeing ended by "rollback" or "commit". We've been fixing this, beating up the programmers responsible and continued monitoring. I don't think it's only due to those queue-like tables, we've really seen a significant improvement on the graphs showing load and cpu usage on the database server after we killed all the "idle in transaction". I can safely relax still some weeks before I need to do more optimization work :-) (oh, btw, we didn't really beat up the programmers ... too big geographical distances ;-)