On 1 August 2011 17:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@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? >
Ah yes, I forgot to mention that bit. I'm using &(tuple1.t_data->t_ctid) to get the second CTID from the old tuple. Is that safe? As far as I could see, this would match the new tuple after a heap update. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
