On 10 June 2013 22:50, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Jun 8, 2013 at 5:00 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> While fiddling with FK tuning, Noah suggested batching trigger
>> executions together to avoid execution overhead.
>>
>> It turns out there is no easy way to write triggers that can take
>> advantage of the knowledge that they are being executed as a set of
>> trigger executions. Some API is required to allow a trigger to
>> understand that there may be other related trigger executions in the
>> very near future, so it can attempt to amortise call overhead across
>> many invocations ("batching").
>>
>> The attached patch adds two fields to the TriggerDesc trigger
>> functions are handed, allowing them to inspect (if they choose) the
>> additional fields and thus potentially use some form of batching.
>
> I'm unclear how this could be used in practice.
As described, you can use it to prepare batches.
> Are the events in a
> "batch" guaranteed to, say, all be related to the same relation?
Good point. I was too focused on the single large statements I was
considering. There would need to some logic to look at relations as
well.
For individual statements it can work well, since all or at least the
majority of events are for a particular relation and we can know which
one that is.
It probably wouldn't work that well for deferred trigger events that
covered a spread of different relations.
Perhaps that's an argument for a final function after all.
--Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services