From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: push AFTER-trigger execution into ModifyTable node |
Date: | 2009-10-31 21:00:38 |
Message-ID: | 4AECA576.2010909@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> On Thu, Oct 29, 2009 at 7:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-31 21:12:43 | Re: WIP: push AFTER-trigger execution into ModifyTable node |
Previous Message | Marko Kreen | 2009-10-31 20:45:29 | Re: Weird PL/Python elog output |