Re: WIP: push AFTER-trigger execution into ModifyTable node - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: push AFTER-trigger execution into ModifyTable node
Date
Msg-id 6162.1257088361@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: push AFTER-trigger execution into ModifyTable node  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP: push AFTER-trigger execution into ModifyTable node
Re: WIP: push AFTER-trigger execution into ModifyTable node
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: per-tablespace random_page_cost/seq_page_cost
Next
From: Marko Tiikkaja
Date:
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node