On Nov 1, 2009, at 10:12 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
