Re: Making AFTER triggers act properly in PL functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making AFTER triggers act properly in PL functions
Date
Msg-id 589.1094702873@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List pgsql-hackers
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> 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).

Yeah.  I can't see that anyone will care about another few bytes in
single-row cases --- the other per-query overheads will swamp this one.
The only cases we've ever heard complaints about are this-query-updated-
umpteen-zillion rows cases, and they were always umpteen zillion cases
of the same trigger.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: APR 1.0 released
Next
From: Bruce Momjian
Date:
Subject: Re: APR 1.0 released