Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 08AA21337BF5 for ; Thu, 10 Feb 2011 14:52:54 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 89144-01 for ; Thu, 10 Feb 2011 18:52:46 +0000 (UTC) X-Greylist: delayed 00:15:36.227159 by SQLgrey-1.7.6 Received: from mail.techbaza.pl (unknown [84.205.162.156]) by mail.postgresql.org (Postfix) with SMTP id D16881337BD5 for ; Thu, 10 Feb 2011 14:52:43 -0400 (AST) Received: from [79.162.73.206] ([79.162.73.206]) by mail.techbaza.pl ; Thu, 10 Feb 2011 19:36:58 +0100 Message-ID: <4D543043.70403@techbaza.pl> Date: Thu, 10 Feb 2011 19:36:51 +0100 From: Piotr Czekalski Organization: TECHBAZA.PL User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Re: DELETE FROM takes forever References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.107 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RDNS_NONE=0.793 X-Spam-Level: X-Archive-Number: 201102/48 X-Sequence-Number: 35124 Are your IDs (in both tables) a subject of index? If so, analyze tables and indexes. If not, create an index for each ID - that may help. Post an explain plan of the query as well. I guess there is full scan instead of index scan, thus running over and over 800 rows vs 110mln rows may take a lot of time. Hope that helps, Piotr W dniu 2011-02-10 18:57, Josh pisze: > Hi > > I'm trying to do a DELETE FROM on my large table (about 800 million > rows) based on the contents of another, moderately large table (about > 110 million rows). The command I'm using is: > > DELETE FROM records WHERE id NOT IN (SELECT id FROM unique_records); > > This process ran for about two weeks before I decided to stop it -- it > was dragging down the DB server. I can understand long-running > processes, but two weeks seems a bit much even for a big table. > > Is this the best way to approach the problem? Is there a better way? > > Some background: The server is version 8.3, running nothing but Pg. > The 'records' table has 'id' as its primary key, and one other index > on another column. The table is referenced by just about every other > table in my DB (about 15 other tables) via foreign key constraints, > which I don't want to break (which is why I'm not just recreating the > table rather than deleting rows). Most of the dependent tables have ON > DELETE CASCADE. The 'unique_records' table is a temp table I got via > something like: SELECT DISTINCT (other_column) id INTO unique_records > FROM records > > > Thanks very much! > > Josh Leder > -- -------------------------------------------------------------- "TECHBAZA.PL" Sp. z o.o. Technologie WEB, eDB& eCommerce OddziaƂ Gliwice ul. Chorzowska 50 44-100 Gliwice tel. (+4832) 7186081 fax. (+4832) 7003289