Tom Lane 312b1a983f Reduce the memory footprint of large pending-trigger-event lists, as per my ... 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.		2008-10-24 23:42:35 +00:00
..
aggregatecmds.c
alter.c
analyze.c
async.c
cluster.c
comment.c
conversioncmds.c
copy.c
dbcommands.c
define.c
discard.c
explain.c
functioncmds.c
indexcmds.c
lockcmds.c
Makefile
opclasscmds.c
operatorcmds.c
portalcmds.c
prepare.c
proclang.c
schemacmds.c
sequence.c
tablecmds.c
tablespace.c
trigger.c	Reduce the memory footprint of large pending-trigger-event lists, as per my	2008-10-24 23:42:35 +00:00
tsearchcmds.c
typecmds.c
user.c
vacuum.c
vacuumlazy.c
variable.c
view.c