On Thu, 26 May 2005, Tom Lane wrote:
> The thoughts I've had about special-casing RI events to save memory
> have to do with the idea of lossy storage. As you accumulate more
> per-row events, at some point it becomes more efficient to forget
> the individual rows and just reapply the original full-table check
> query when it's time to check the constraint. So if we could recognize
One problem with that is that it works for the constraint check but not
for referential actions, although if we instead fired the referential
actions truly immediately rather than queued to statement end that'd
prevent those from being an issue. The only thing there is that we'd have
to also have a constraint check for at least set default.
> RI events as being associated with the same constraint, and keep track
> of how many are pending for each constraint, we could make a decision to
> discard the queue and instead register one event to apply a full-table
> check. It's not clear how to do that efficiently though.
Yeah, I was thinking we could keep a separate structure for (foreign key
trigger oid, action) where we could keep track of a current count and
whether or not we've consolidated already and scan the queue when we do
the consolidation removing items for that oid. That's still not very good
though.
