On Wed, 8 Sep 2004, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > On Wed, 8 Sep 2004, Tom Lane wrote: > >> As long as we're talking about hack-slash-and-burn on this data > >> structure ... > > > Where the OtherInformation could be shared within the statement (for > > identical events)? I think it'd be problematic to try sharing between > > statements. > > Yeah, I had come to the same conclusion after more thought. But we > could certainly aggregate all the similar events generated by a single > query into a common status structure.
Definately. The ~20 byte/row gain for large updates/insert/delete is worth it. I think it'd actually increase the size for the single row case since we'd have the pointer to deal with (we could use a flag that tells us whether this item actually has a pointer to a shared status structure or just contains the status structure but that seems kinda ugly). > > But, I'm sort of assuming the following are true: > > Once a group of items is marked to be run, all items will run even if set > > constraints ... deferred happens while the run occurs. > > That's a good question. If the first trigger firing tries to set the > event deferred, what happens to the remaining triggers? The SQL spec > doesn't even touch this question, so I think we are at liberty to do > what we like. I don't see that it's unreasonable to continue to fire > events that were marked as firable when we reached the end of the > current statement. That's what I figured, especially if a function called in an update that does a set constraints doesn't act upon the triggers being queued effectively until the end of statement. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster