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 DC810DA3DF for ; Mon, 14 Nov 2005 20:00:38 -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 44024-01 for ; Tue, 15 Nov 2005 00:00:35 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noao.edu (noao.edu [140.252.1.54]) by svr1.postgresql.org (Postfix) with ESMTP id 4BF26DA3E6 for ; Mon, 14 Nov 2005 20:00:37 -0400 (AST) X-TFF-CGPSA-Version: 1.4f1 X-TFF-CGPSA-Filter: Scanned Received: from weaver.tuc.noao.edu ([140.252.14.8] verified) by noao.edu (CommuniGate Pro SMTP 5.0.1) with ESMTPS id 21636357; Mon, 14 Nov 2005 17:00:36 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by weaver.tuc.noao.edu (8.13.1/8.13.1) with ESMTP id jAF00Zva000706; Mon, 14 Nov 2005 17:00:36 -0700 Message-ID: <43792523.5090003@noao.edu> Date: Mon, 14 Nov 2005 17:00:35 -0700 From: Steve Wampler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: Postgres-performance Subject: Re: Help speeding up delete References: <43790A99.9050603@noao.edu> <4162.1132011763@sss.pgh.pa.us> In-Reply-To: <4162.1132011763@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.005 required=5 tests=[AWL=0.005] X-Spam-Score: 0.005 X-Spam-Level: X-Archive-Number: 200511/234 X-Sequence-Number: 15491 Tom Lane wrote: > 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 ;-) I was afraid you'd say that :-) I'm not officially involved in this project anymore and was hoping for a fix that wouldn't drag me back in. The security issues aren't a concern because this DB is *well* hidden from the outside world (it's part of a telescope control system behind several firewalls with no outside access). However, the data-loss-grade bugs issue *is* important. We'll try to do the upgrade as soon as we get some cloudy days to actually do it! Is the performance behavior that we're experiencing a known problem with 7.2 that has been addressed in 7.4? Or will the upgrade fix other problems while leaving this one? > 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. Thanks! Steve -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud.