Re: Batch API for After Triggers

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Batch API for After Triggers
Date: 2013-06-09 10:33:24
Message-ID: 20130609103323.GB12924@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 09, 2013 at 10:15:09AM +0100, Simon Riggs wrote:
> As I mentioned in my post, I did consider that and then chose not to
> do that. However, having a final func is a major modification in the
> way that we specify trigger functions. We'd also need to cope with
> recursive trigger execution, which would mean the final func would get
> called potentially many times, so there's no way of knowing if the
> final func is actually the last call needed. That sounded complex and
> confusing to me.
>
> The proposed API allows you to do exactly that anyway, more easily, by
> just waiting until tg_event_num == tg_tot_num_events.

Can you signal partial completion? For example, if a trigger know that
blocks of 10,000 are optimal and it sees tg_tot_num_events == 1,000,000
that it could do work every 10,000 entries, as in when:

(tg_event_num % 10000) == 0 || tg_event_num == tg_tot_num_events

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-06-09 11:58:42 Re: Batch API for After Triggers
Previous Message Craig Ringer 2013-06-09 10:20:14 Re: Vacuum, Freeze and Analyze: the big picture