Re: Batch API for After Triggers

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Batch API for After Triggers
Date: 2013-06-09 04:08:50
Message-ID: 20130609040850.GO7200@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> While fiddling with FK tuning, Noah suggested batching trigger
> executions together to avoid execution overhead.

I like the general idea, but I'd prefer a way to avoid having to queue
up tons of trigger events to be executed in the first place.
Aggregates do this by providing a way to store up information to be
processed by an eventual 'final' function. Another option, as Kevin
asked about, would be statement level triggers which are able to see
both the OLD and the NEW versions of the relation.

The per-row trigger option with a way to be called immediately and then
store what it cares about for a later final function strikes me as very
generalized and able to do things that the statement-level option
couldn't, but I'm not sure if there's a use-case that could solve which
the OLD/NEW statement trigger capability couldn't.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-06-09 04:38:19 Re: [COMMITTERS] pgsql: Don't downcase non-ascii identifier chars in multi-byte encoding
Previous Message Andrew Dunstan 2013-06-09 03:50:53 Re: [COMMITTERS] pgsql: Don't downcase non-ascii identifier chars in multi-byte encoding