Re: WIP: push AFTER-trigger execution into ModifyTable node
От | Marko Tiikkaja |
---|---|
Тема | Re: WIP: push AFTER-trigger execution into ModifyTable node |
Дата | |
Msg-id | 4AECA576.2010909@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: WIP: push AFTER-trigger execution into ModifyTable node (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: WIP: push AFTER-trigger execution into ModifyTable node
|
Список | pgsql-hackers |
Greg Stark wrote: > On Thu, Oct 29, 2009 at 7:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Pipelined execution would be nice but I really doubt that it's worth >> what we'd have to give up to have it. The one-at-a-time behavior will >> be simple to understand and reliable to use. Concurrent execution won't >> be either. > > I think the ideal way to get pipelined execution will be to detect the > cases where it's safe, ie, no deletes, inserts, or updates, no > recursive calls, and only one call site, and inline the sql directly > into the callsite. Actually we could do that even if there are two > callsites if there are no volatile functions but estimating whether > that would be a win or a loss would be hard. What I've had in mind is pipelining the execution only when it doesn't have *any* impact on the outcome. This would mean only allowing it when the top-level statement is either a SELECT or an INSERT. Also, UPDATEs and DELETEs inside CTEs can't have the same result relations. Whether or not we want to break the expected(?) behaviour for statement-level triggers, I have no opinion to way or another. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: