On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
<marko.tiikkaja@cs.helsinki.fi> wrote:
> 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.
You'd also have to disallow the case when there are any triggers on
the INSERT, or where there are any triggers on anything else (because
they might access the target table of the INSERT). This will end up
being so restricted as to be useless.
...Robert