Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 041F763372D for ; Fri, 7 May 2010 11:17:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 94613-06 for ; Fri, 7 May 2010 14:17:17 +0000 (UTC) X-Greylist: delayed 00:06:42.049854 by SQLgrey-1.7.6 Received: from tanagra.summersault.com (tanagra.summersault.com [12.161.105.149]) by mail.postgresql.org (Postfix) with ESMTP id CBE826335EE for ; Fri, 7 May 2010 11:17:16 -0300 (ADT) Received: (qmail 51071 invoked from network); 7 May 2010 14:10:31 -0000 Received: from simba.summersault.com (HELO localhost) (192.168.97.182) by tanagra.summersault.com with SMTP; 7 May 2010 14:10:31 -0000 Date: Fri, 7 May 2010 10:10:31 -0400 From: Mark Stosberg Cc: pgsql-performance@postgresql.org Subject: Re: debugging handle exhaustion and 15 min/ 5mil row delete Message-ID: <20100507101031.3442dd08@summersault.com> In-Reply-To: <4BE3C4C9.60601@uci.cu> References: <20100507093742.20c715b1@summersault.com> <4BE3C4C9.60601@uci.cu> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.12.9; i486-pc-linux-gnu) 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.889 tagged_above=-10 required=5 tests=BAYES_00=-1.9, MISSING_HEADERS=1.021, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201005/22 X-Sequence-Number: 38606 > You can use TRUNCATE instead DELETE. TRUNCATE is more efficient and > faster that DELETE. Thanks for the suggestion. However, TRUNCATE is not compatible with Slony, and we also have some rows which remain in table. > Now, we need more information about your system to give you a certain > solution: > Are you using a RAID controller for you data? Yes. > Do you have separated the xlog directory from the data directory? No. > Which is your Operating System? FreeBSD. > Which is you architecture? i386. Thanks for the feedback. I'm going to try batching the deletes for now, which is approach was worked well for some of our other long-running deletes. Mark