Re: on update / on delete performance of foreign keys
От | PFC |
---|---|
Тема | Re: on update / on delete performance of foreign keys |
Дата | |
Msg-id | opsk8g5ht5th1vuj@musicbox обсуждение исходный текст |
Ответ на | Re: on update / on delete performance of foreign keys (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Список | pgsql-general |
It's a bit more complicated than that as there are also locking issues, like what if other processes insert rows while some others are being deleted, really the whole thing isn't trivial. >> Since postgres already incoporates code to check foreign keys more >> efficiently (when doing alter table ... add constraint .. foreign key, >> postgres seems to use a merge or a hash join, instead of a nested loop), >> I wondered how hard it would be to use this for the triggers too. >> >> I imagined creating a statement-level trigger in parallel to the >> row-level triggers, and defining some threshold (let's say, more than >> 10% of the rows deleted). If the threshold is reached, the row-level >> trigger would just do nothing, and the statement-level trigger would >> delete the referencing records doing a join. >> >> Would this be feasable? And would it be something a newbie could tackle, >> or is it more involved than I think?
В списке pgsql-general по дате отправления: