Re: Speeding up DELETEs on table with FKs ...

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: Speeding up DELETEs on table with FKs ...
Дата
Msg-id 20041010212658.O54093@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: Speeding up DELETEs on table with FKs ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Speeding up DELETEs on table with FKs ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 10 Oct 2004, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@postgresql.org> writes:
>> I posted to -sql the other day about an atrociously slow DELETE on a table
>> that has two FKs to a 'parent' table ... if the # of records in the table
>> that match the condition is 1, its fast ... in the sample I'm working
>> with, there are 1639 records in the table ...
>
> "parent" table?  A DELETE doesn't check FKs in the table it's deleting.
> What it checks are FKs in other tables that reference items in the
> deletion table.  You sure you are worrying about the right set of FKs?

'k, now that I've seen the error of my ways *groan*  I've gone back 
through, and checked for what is referencing that table, and there is only 
one place that is, and it does have an INDEX:

> explain analyze select * from table where raw_id = 20722;
QUERYPLAN
 

-----------------------------------------------------------------------------------------------------------------------------------
IndexScan using ind_raw_id on table  (cost=0.00..3.09 rows=1 width=122) (actual time=0.33..0.33 rows=0 loops=1)   Index
Cond:(raw_id = 20722::numeric) Total runtime: 0.37 msec
 
(3 rows)

and raw_id is the primary key in the table that I'm trying to run the 
delete on, and an EXPLAIN ANALYZE for that one shows slightly slower, but 
similar results (it a much bigger table) ...

And, doing a join of the two tables based on raw_id shows that the indices 
are being used:

> explain select bdar.detail_id from detail bda,detail_raw bdar where bdar.raw_avl_id = bda.raw_avl_id;
                                   QUERY PLAN
 
---------------------------------------------------------------------------------------------------------------------
MergeJoin  (cost=0.00..29829.28 rows=250567 width=37)   Merge Cond: ("outer".raw_avl_id = "inner".raw_avl_id)   ->
IndexScan using ind_raw_avl_id on detail bda  (cost=0.00..8456.34 rows=250567 width=12)   ->  Index Scan using
pk_detail_rawon detail_raw bdar  (cost=0.00..16941.06 rows=269349 width=25)
 
(4 rows)

Now, the DELETE query that I'm trying to run is to delete 9997 rows from 
the table, so that means 9997 checks to detail as well, to make sure 
raw_id isn't being used, correct?

Am I in the right ballpark now with this?  Or am I still totally lost?


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Speeding up DELETEs on table with FKs ...
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: CVS fixed ...