From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using results from INSERT ... RETURNING |
Date: | 2009-10-08 20:16:38 |
Message-ID: | 603c8f070910081316xd0bc6a5ndf3b691cdce876ad@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 8, 2009 at 4:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> While we're discussing explain output ... what about triggers?
>>> An important aspect of this change is that at least the row-level
>>> triggers are now going to be charged as runtime of the
>>> Dml-or-whatever-we-call-it node. Should we rearrange the explain
>>> output so that the printout for trigger runtimes is associated
>>> with those nodes too? If so, what about statement-level triggers?
>
>> That's not a bad idea, though it wouldn't bother me much if we left it
>> for a follow-on patch.
>
> After cogitating on this for a few minutes, it seems to me that the
> right thing to do is to push the calling of statement-level triggers
> into the Dml node too. That is, ExecDml() would be responsible for
> calling BEFORE STATEMENT triggers at the start of its first call,
> and for calling AFTER STATEMENT triggers at the end of its last
> call (just before it returns NULL). This would mean that all trigger
> activity is now associated with a plan node and should be reported
> that way by EXPLAIN. We could get rid of the rather warty top-level
> XML item for triggers and make the trigger instrumentation outputs
> just be another plan node property.
>
> Aside from having a cleaner EXPLAIN output design, this would mean that
> triggers in the planned WITH RETURNING scenario fire in the order you'd
> expect if we are considering the WITH RETURNING queries to be done
> sequentially and before the main query. From a user's standpoint it
> would look just like you'd issued the queries sequentially, except that
> the RETURNING data is held for use in the main query.
That seems like a good design. I hate to have you spend too much time
on any one patch at this stage of the game, though. Is this a big
enough change that we should send it back for the patch author (or
other interested parties) to do make that change, or are you just
going to knock it out?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-08 20:43:42 | Re: Using results from INSERT ... RETURNING |
Previous Message | Robert Haas | 2009-10-08 20:13:59 | Re: Using results from INSERT ... RETURNING |