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?
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
