Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?
Дата
Msg-id 16581.1553203016@sss.pgh.pa.us
обсуждение исходный текст
Ответ на EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey indexdespite EXPLAINing that it would?  (Gunther <raj@gusw.net>)
Ответы Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey indexdespite EXPLAINing that it would?
Список pgsql-performance
Gunther <raj@gusw.net> writes:
> I have 250 rows to delete, but they are a target to a bunch of child 
> tables with foreign key on delete cascade.

> EXPLAIN DELETE FROM Foo WHERE id = (SELECT fooId FROM Garbage);

> shows me that it uses the nested loop by Foo_pkey index to find the 250 
> items from Garbage to be deleted.

> But once that starts, I see HUGE amount of read activity from the 
> tablespace Foo_main that contains the Foo table, and only the Foo table, 
> not the Foo_pkey, not any other index, not any other child table, not 
> even the toast table for Foo is contained in that tablespace (I have the 
> toast table diverted with symlinks to another volume).

I'm betting you neglected to index the referencing column for one
or more of the foreign keys involved.  You can get away with that
as long as you're not concerned with the speed of DELETE ...

            regards, tom lane


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

Предыдущее
От: Gunther
Дата:
Сообщение: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey indexdespite EXPLAINing that it would?
Следующее
От: David Rowley
Дата:
Сообщение: Re: Poor man's partitioned index .... not being used?