I wrote: > Actually, I'd really like to get it back down to the 7.4 size, which was > already too big :-(. That might be a vain hope though.
As long as we're talking about hack-slash-and-burn on this data structure ... The cases where people get annoyed by the size of the deferred trigger list are nearly always cases where the exact same trigger is to be fired on a large number of tuples from the same relation (ie, we're doing a mass INSERT, mass UPDATE, etc). Since it's the exact same trigger, all these events must have identical deferrability properties, and will all be fired (or not fired) at the same points. So it seems to me that we could refactor the data structure into some per-trigger stuff (tgoid, relid, xid, flag bits) associated with an array of per-event records that hold only the old/new ctid fields, and get it down to about 12 bytes per tuple instead of forty-some. However this would lose the current properties concerning event firing order. Could we do something where each event stores just a pointer to some per-trigger data (shared across all like events) plus the old and new ctid fields? 16 bytes is still way better than 44. Thoughts? Am I missing some reason why we could not share status data across multiple tuples, if their events are otherwise identical? If we fail partway through processing the trigger events, I don't see that we care exactly where. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match