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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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


  • From: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
  • To: Greg Stark <gsstark(at)mit(dot)edu>
  • Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: WIP: push AFTER-trigger execution into ModifyTable node
  • Date: Sat, 31 Oct 2009 23:00:38 +0200
  • Message-id: <4AECA576.2010909@cs.helsinki.fi> <text/plain>

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.

Regards,
Marko Tiikkaja




Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group