Message-ID: <4614784F.3040901@obviously.com>
Date: Wed, 04 Apr 2007 21:17:19 -0700
From: Bryce Nesbitt <bryce1@obviously.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.1.2) Gecko/20061107 SUSE/1.1.1-0.1 SeaMonkey/1.1.1
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: Very slow DELETE on 4000 rows of 55000 row table
References: <4611EFE1.5010400@obviously.com> <21308.1175583840@sss.pgh.pa.us>
In-Reply-To: <21308.1175583840@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Bryce Nesbitt <bryce1@obviously.com> writes:
>   
>> I've got a DELETE FROM that seems to run forever, pegging the CPU at
>> 100%.  I can't figure out why it's slow.  Any clues?
>>     
>
> Unindexed foreign key constraints pointing to this table, perhaps?
> EXPLAIN ANALYZE would give a great deal more clue than plain EXPLAIN.
>
> 			regards, tom lane
>   
Hmm, excellent point.  There is a column with no index that points to
the table in question:

Indexes:
    "eg_order_line_pkey" PRIMARY KEY, btree (order_line_id)
    "ixf8331222783867cc" btree (order_id)
Foreign-key constraints:
    "fkf8331222783867cc" FOREIGN KEY (order_id) REFERENCES
eg_order(order_id)
    "fkf83312228edf278d" FOREIGN KEY (invoice_id) REFERENCES
eg_invoice(invoice_id)
    "order_line_to_cso" FOREIGN KEY (cso_id) REFERENCES eg_cso(cso_id)

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.