[snip]
> This needs to be improved (if we can't get rid of the lookup completely,
> maybe use a hash table instead of sequential scan?) but it's much too
> late to consider fixing it for 7.1 :-(.
>
> Actually, though, it might be even stupider than that: it looks like
> the queue should only be searched if the tuple being deleted was
> inserted/modified earlier in the same transaction. Assuming that that
> doesn't apply to Bill's case, the only thing I can see that could be
> causing O(N^2) behavior is the lappend() in deferredTriggerAddEvent.
> That's simple enough that we *could* fix it for 7.1 ...
>
This would be a welcome improvement. I have for a long time noticed
very slow delete performance when deleting a large number of records in one
command. I can give more detail if so desired.
