Re: Scaling up deferred unique checks and the after trigger queue

2009/10/26 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On Mon, 2009-10-26 at 13:28 +0000, Dean Rasheed wrote:
>
>> It works for all kinds of trigger events,
>> and is intended as a complete drop-in replacement for the after
>> triggers queue.
>
>> > All of those seem false in the general case. What will you do?
>>
>> At this point I'm looking for more feedback as to whether any of this
>> is a show-stopper, before I expend more effort on this patch.
>
> I see no show stoppers, only for you to look at ways of specifying that
> this optimization is possible for particular cases. I think we might be
> able to make the general statement that it will work for all after
> triggers that execute STABLE or IMMUTABLE functions. I don't think we
> can assume that firing order is irrelevant for some cases, e.g. message
> queues.
>

Hmm, thinking about this some more... one thing this patch does is to
separate out the queues for "regular" triggers from those for RI
triggers and deferrable constraint checks. ITSM that row-order only
really matters for the former. It's also the case that for these
triggers there will never be any other choice but to execute them one
at a time, so they may as well just spool to a file rather than using
a TID bitmap.

The bitmaps are probably only useful for constraint triggers, where a
bulk check can be used instead of executing individual triggers for
each row, if enough rows are modified.

- Dean