Re: Making AFTER triggers act properly in PL functions

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Making AFTER triggers act properly in PL functions
Date: 2004-09-08 23:10:33
Message-ID: 20040908151211.E55137@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2004-09-08 23:12:37 Re: Geometry regression test failure, CVS HEAD, Mac OS/X
Previous Message Devrim GUNDUZ 2004-09-08 22:56:42 SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0