From: | Bryce Nesbitt <bryce1(at)obviously(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Very slow DELETE on 4000 rows of 55000 row table |
Date: | 2007-04-05 04:17:19 |
Message-ID: | 4614784F.3040901@obviously.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
> Bryce Nesbitt <bryce1(at)obviously(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Broersma Jr | 2007-04-05 04:46:10 | Re: Very slow DELETE on 4000 rows of 55000 row table |
Previous Message | Sumeet | 2007-04-05 03:17:54 | slow query |