Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 3F10E9FB90F for ; Thu, 5 Apr 2007 01:46:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 33424-02 for ; Thu, 5 Apr 2007 01:46:11 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from web31801.mail.mud.yahoo.com (web31801.mail.mud.yahoo.com [68.142.207.64]) by postgresql.org (Postfix) with SMTP id 9E7699FB739 for ; Thu, 5 Apr 2007 01:46:11 -0300 (ADT) Received: (qmail 65598 invoked by uid 60001); 5 Apr 2007 04:46:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=O4OUfCNd5qYMHK089l/T+5GCVHNYEeMZ+aFoIkZ91xIzm9oeWWk5BTJMsjz+u8W4Lnd4F9dCDvcCESBDabLarOM6n0WTWMSlAdQanyZWHzKQoeQ9Hg0vjClInkJTGLqffR4hd9/BQXpZkJjnmNURn5QcipCBcdHuDnq+/jl9HUw=; X-YMail-OSG: kOM3XHkVM1m05GrwEO36mFf3128QXZTYoOnNSuWZKrxoMue_hr6.IlU.FYsUQmhxplTHgw-- Received: from [75.84.89.248] by web31801.mail.mud.yahoo.com via HTTP; Wed, 04 Apr 2007 21:46:10 PDT Date: Wed, 4 Apr 2007 21:46:10 -0700 (PDT) From: Richard Broersma Jr Subject: Re: Very slow DELETE on 4000 rows of 55000 row table To: Bryce Nesbitt , pgsql-sql@postgresql.org In-Reply-To: <4614784F.3040901@obviously.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <880852.63314.qm@web31801.mail.mud.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.915 tagged_above=0 required=5 tests=AWL=-1.255, BAYES_40=-0.185, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, DNS_FROM_RFC_WHOIS=1.447 X-Spam-Level: * X-Archive-Number: 200704/62 X-Sequence-Number: 28062 > But I DELETE all conflicting those rows prior to the slow DELETE, just > so the FK check is never hit. Should I be looking at subverting the FK > check mechanism somehow? The necessary index would be huge, and > relevant only on this particular operation which happens every few > months, if that. true, but without an index, it still has to scan the table just to be sure.