X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 912A2DB758 for ; Mon, 14 Nov 2005 19:42:44 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 26651-05 for ; Mon, 14 Nov 2005 23:42:41 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 5816EDB715 for ; Mon, 14 Nov 2005 19:42:43 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jAENghuu004163; Mon, 14 Nov 2005 18:42:43 -0500 (EST) To: Steve Wampler cc: Postgres-performance Subject: Re: Help speeding up delete In-reply-to: <43790A99.9050603@noao.edu> References: <43790A99.9050603@noao.edu> Comments: In-reply-to Steve Wampler message dated "Mon, 14 Nov 2005 15:07:21 -0700" Date: Mon, 14 Nov 2005 18:42:43 -0500 Message-ID: <4162.1132011763@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.006 required=5 tests=[AWL=0.006] X-Spam-Score: 0.006 X-Spam-Level: X-Archive-Number: 200511/229 X-Sequence-Number: 15486 Steve Wampler writes: > We've got an older system in production (PG 7.2.4). Recently > one of the users has wanted to implement a selective delete, > but is finding that the time it appears to take exceeds her > patience factor by several orders of magnitude. Here's > a synopsis of her report. It appears that the "WHERE > id IN ..." is resulting in a seq scan that is causing > the problem, but we're not SQL expert enough to know > what to do about it. > Can someone point out what we're doing wrong, or how we > could get a (much) faster delete? Thanks! Update to 7.4 or later ;-) Quite seriously, if you're still using 7.2.4 for production purposes you could justifiably be accused of negligence. There are three or four data-loss-grade bugs fixed in the later 7.2.x releases, not to mention security holes; and that was before we abandoned support for 7.2. You *really* need to be thinking about an update. regards, tom lane