Re: Making AFTER triggers act properly in PL functions

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Making AFTER triggers act properly in PL functions
Дата
Msg-id 20040908151211.E55137@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Hans Groschwitz"
Дата:
Сообщение: Plannings on Implementation of DECLARE CURSOR x for SELECT ... FOR UPDATE / UPDATE ... WHERE CURRENT OF ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Making AFTER triggers act properly in PL functions