Re: Very slow DELETE on 4000 rows of 55000 row table
От | Bryce Nesbitt |
---|---|
Тема | Re: Very slow DELETE on 4000 rows of 55000 row table |
Дата | |
Msg-id | 4614784F.3040901@obviously.com обсуждение исходный текст |
Ответ на | Re: Very slow DELETE on 4000 rows of 55000 row table (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Very slow DELETE on 4000 rows of 55000 row table
|
Список | pgsql-sql |
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.
В списке pgsql-sql по дате отправления: