Re: Making AFTER triggers act properly in PL functions

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> 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).

I have given up on this idea for the moment, as on further examination
it seems to require a lot of work to get any improvement. The code I
just committed uses a 32-byte (on 32-bit machines anyway) data structure
for each trigger event. Allowing for palloc overhead, that's 40 bytes
per event. If we separated it into two parts, the per-tuple part would
still need 20 bytes per event (a list link pointer, a link to the shared
part, and 2 tuple item pointers). Because palloc would round such a
requested size up to the next power of 2, there would actually be no
savings at all, unless we were willing to hack up palloc to have a
special case for this request size. Which is not beyond the realm of
reason, certainly, but even with no round-up the effective space
requirement would be 28 bytes. Doing a lot of work to get from 40 to
28 bytes doesn't excite me.

I spent some time thinking about whether the per-tuple stuff could be
kept in large arrays, so that we eliminate both the list links and the
palloc overhead, bringing it down to 16 bytes per event. This would be
enough savings to be worth some trouble, but the management seems really
messy, mainly because retail deletion of fired events isn't easy anymore.
I decided trying to get this done for 8.0 wasn't going to be practical.
Possibly someone will take another look in a future release cycle.

regards, tom lane