Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> I've been thinking some more about the long-standing problem of the
> AFTER TRIGGER queue using too much memory, and I think that the
> situation can be improved by using some basic compression.
> Currently each event added to the AFTER TRIGGER queue uses 10 bytes
> per trigger per row for INSERTs and DELETEs, and 16 for UPDATEs. The
> attached patch reduces this down to just 1 byte in a number of common
> cases.
Ummm ... I only read the data structure comments, not the code, but I
don't see where you store the second CTID for an update event?
regards, tom lane