Re: WIP: push AFTER-trigger execution into ModifyTable node - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: WIP: push AFTER-trigger execution into ModifyTable node
Date
Msg-id 4AECA576.2010909@cs.helsinki.fi
Whole thread Raw
In response to Re: WIP: push AFTER-trigger execution into ModifyTable node  (Greg Stark <gsstark@mit.edu>)
Responses Re: WIP: push AFTER-trigger execution into ModifyTable node  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Weird PL/Python elog output
Next
From: Robert Haas
Date:
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node