Re: on update / on delete performance of foreign keys

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?