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

From Stephan Szabo
Subject Re: Making AFTER triggers act properly in PL functions
Date
Msg-id 20040908151211.E55137@megazone.bigpanda.com
Whole thread Raw
In response to Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 8 Sep 2004, Tom Lane wrote:

> I wrote:
> > Actually, I'd really like to get it back down to the 7.4 size, which was
> > already too big :-(.  That might be a vain hope though.
>
> As long as we're talking about hack-slash-and-burn on this data
> structure ...
>
> The cases where people get annoyed by the size of the deferred trigger
> list are nearly always cases where the exact same trigger is to be fired
> on a large number of tuples from the same relation (ie, we're doing a
> mass INSERT, mass UPDATE, etc).  Since it's the exact same trigger, all
> these events must have identical deferrability properties, and will all
> be fired (or not fired) at the same points.
>
> So it seems to me that we could refactor the data structure into some
> per-trigger stuff (tgoid, relid, xid, flag bits) associated with an
> array of per-event records that hold only the old/new ctid fields, and
> get it down to about 12 bytes per tuple instead of forty-some.
>
> However this would lose the current properties concerning event
> firing order.  Could we do something where each event stores just
> a pointer to some per-trigger data (shared across all like events)
> plus the old and new ctid fields?  16 bytes is still way better than
> 44.

Something like the main items being:- next pointer for list- old ctid- new ctid- pointer to other information

with other information:- event- relid,- done xid- n_items- dte_item array

Where the OtherInformation could be shared within the statement (for
identical events)? I think it'd be problematic to try sharing between
statements.

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.If set constraints is called inside a function used in a
statement(like
 
update foo set bar=f(baz) where f() calls set constraints) the entire
queue runs with one particular deferrability.If an error occurs, either the entire set of event objects for the
statement are going away because they're new, or if it was something run
from set constraints we're going to want to rerun the entire set anyway.


pgsql-hackers by date:

Previous
From: "Hans Groschwitz"
Date:
Subject: Plannings on Implementation of DECLARE CURSOR x for SELECT ... FOR UPDATE / UPDATE ... WHERE CURRENT OF ...
Next
From: Tom Lane
Date:
Subject: Re: Making AFTER triggers act properly in PL functions