Robert Haas <robertmh...@gmail.com> writes:
> On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
> <marko.tiikk...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
