Skip site navigation (1) Skip section navigation (2)

Re: WIP: push AFTER-trigger execution into ModifyTable node

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node
Date: 2009-10-31 21:12:43
Message-ID: 603c8f070910311412j74031499qc310f5d85089af1f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
> Greg Stark wrote:
>>
>> On Thu, Oct 29, 2009 at 7:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>
>>> Pipelined execution would be nice but I really doubt that it's worth
>>> what we'd have to give up to have it.  The one-at-a-time behavior will
>>> be simple to understand and reliable to use.  Concurrent execution won't
>>> be either.
>>
>> I think the ideal way to get pipelined execution will be to detect the
>> cases where it's safe, ie, no deletes, inserts, or updates, no
>> recursive calls, and only one call site, and inline the sql directly
>> into the callsite. Actually we could do that even if there are two
>> callsites if there are no volatile functions but estimating whether
>> that would be a win or a loss would be hard.
>
> 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.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: John MurtariDate: 2009-10-31 22:47:32
Subject: Re: Patch set under development to add usage reporting.
Previous:From: Marko TiikkajaDate: 2009-10-31 21:00:38
Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group