Re: Batch API for After Triggers

On 9 June 2013 14:56, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>> On 8 June 2013 22:25, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>>> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>
>> There are also difficulties in semantics, since when
>> we have OLD and NEW at row level we know we are discussing the same
>> row. With sets of OLD and NEW we'd need to be able to link the
>> relations back together somehow, which couldn't be done by PK since
>> that could change. So we'd need to invent some semantics for a
>> "linking identifier" of some description. Which once we've done it
>> would be used by people to join them back together again, which is
>> what we already had in the first place. So my take is that it sounds
>> expressive, but definitely not performant.
>
> I have used a feature like this in other database products, and can
> say from experience that these relations in a statement trigger can
> be very useful without the linkage you propose. I can see how the
> linkage could potentially be useful, but if that is the only
> hang-up, we would be adding a powerful feature without it.

What I'm trying to do is tune FKs, which are currently implemented as
after row triggers. Hence why I'm looking at ways to speed up after
row triggers.

Suggesting I work on after statement triggers would imply you think
that FKs should/could be rewritten as after statement triggers. Is
that what you mean?

Doing it that way would mean rewriting a lot of code and would still
have problems 2 and 3 identified above. I can't imagine anybody would
go for that, but if you have a sketch of how it might work we can
consider it.

>> Since my objective is performance, not standards, I don't see a reason
>> to work on that, yet. I might have time to work on it later, lets see.
>
> This seems like it has some overlap with the delta relations I will
> need to generate for incremental maintenance of materialized views,
> so we should coordinate on those efforts if they happen to occur
> around the same time.

IMHO you should use Andres' logical changeset extraction for
incremental maintenance for mat views. Doing mat view maintenance
using triggers would be choosing the lower performance option.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services