Re: WIP: push AFTER-trigger execution into ModifyTable node
От | Tom Lane |
---|---|
Тема | Re: WIP: push AFTER-trigger execution into ModifyTable node |
Дата | |
Msg-id | 22427.1256777113@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: push AFTER-trigger execution into ModifyTable node (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>) |
Ответы |
Re: WIP: push AFTER-trigger execution into ModifyTable node
|
Список | pgsql-hackers |
Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes: > Like we've discussed before, WITH (.. RETURNING ..) is probably most > useful for moving rows from one table to another. When you're moving a > lot of rows around, there's some point where I believe this execution > strategy will be a lot slower than the traditional approach due to > storing the RETURNING results on disk. I've been thinking that in some > cases we could inline the CTE for this to actually be a quite > significant performance benefit, so I'm not too fancy about the approach > you're suggesting. Well, this is what we need to nail down *now*. Are we going to say that use of WITH(RETURNING) means you forfeit all guarantees about order of trigger firing? Short of that, I don't believe that it is sane to think about pipelining such things. And if we do do that, it sounds like a security hole to me, because the owner of the trigger isn't the one who agreed to forfeit predictability. regards, tom lane
В списке pgsql-hackers по дате отправления: