• Tom Lane's avatar
    Reduce the memory footprint of large pending-trigger-event lists, as per my · 312b1a98
    Tom Lane authored
    recent proposal.  In typical cases, we now need 12 bytes per insert or delete
    event and 16 bytes per update event; previously we needed 40 bytes per
    event on 32-bit hardware and 80 bytes per event on 64-bit hardware.  Even
    in the worst case usage pattern with a large number of distinct triggers being
    fired in one query, usage is at most 32 bytes per event.  It seems to be a
    bit faster than the old code as well, due to reduction of palloc overhead.
    
    This commit doesn't address the TODO item of allowing the event list to spill
    to disk; rather it's trying to stave off the need for that.  However, it
    probably makes that task a bit easier by reducing the data structure's
    dependency on pointers.  It would now be practical to dump an event list to
    disk by "chunks" instead of individual events.
    312b1a98
trigger.c 112 KB