Re: Scaling up deferred unique checks and the after trigger queue
От | Simon Riggs |
---|---|
Тема | Re: Scaling up deferred unique checks and the after trigger queue |
Дата | |
Msg-id | 1256564791.8450.11195.camel@ebony обсуждение исходный текст |
Ответ на | Re: Scaling up deferred unique checks and the after trigger queue (Dean Rasheed <dean.a.rasheed@googlemail.com>) |
Ответы |
Re: Scaling up deferred unique checks and the after trigger
queue
Re: Scaling up deferred unique checks and the after trigger queue |
Список | pgsql-hackers |
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. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: