2009/10/26 Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
