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
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 |