On Nov 1, 2009, at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
>> <marko.tiikkaja@cs.helsinki.fi> wrote:
>>> 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.
>
> Well, it's already the case that BEFORE triggers shouldn't count on
> seeing any particular subset of a statement's results completed.
> We could define AFTER triggers as all being fired after the entire
> statement is complete (which is not the direction my patch was headed
> in, but I have no allegiance to that). So I think we could define our
> way out of the trigger timing issue, and I don't see any big objection
> to limiting pipelining to cases where the sub-statements' target
> tables
> don't overlap.
Hmm... yeah. If we do that, then pipelining becomes a much more
feasible optimization. I think that definition is a bit more likely
to result in POLA violations, but I'm not sure by how much.
> However, this still doesn't address the problem of what happens when
> the
> top-level select fails to read all of the CTE output (because it has a
> LIMIT, or the client doesn't read all the output of a portal, etc
> etc).
> Partially executing an update in such cases is no good.
Well, like you said elsewhere on this thread, you just have to finish
out any remaining bits after the main query completes.
...Robert
