Skip site navigation (1) Skip section navigation (2)

Re: WIP: push AFTER-trigger execution into ModifyTable node

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node
Date: 2009-10-29 00:45:13
Message-ID: 22427.1256777113@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-10-29 02:10:53
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node
Previous:From: Marko TiikkajaDate: 2009-10-29 00:21:09
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group