FAQ

On 8 June 2013 22:25, Kevin Grittner wrote:
Simon Riggs wrote:
Comments please.
How much of this problem space do you think could be addressed by
providing OLD and NEW *relations* to AFTER EACH STATEMENT triggers?
It's a reasonable question because those two things sound a little
like they might be related.

Providing the proposed additional info costs almost nothing since the
work to calculate that info is already performed. I've written this
patch since it was trivial to do so, while inspecting the code to see
if it was possible. As it now turns out, I'll be putting most effort
into the WHEN clause approach for FKs, but there's no reason why
others like Slony or pgmemcache wouldn't benefit here also - hence
posting the patch. The proposed API changes don't conflict in any way
with the feature you propose.

Providing the whole OLD and NEW sets as relations to a trigger would
require significant resources and wouldn't be done for performance
reasons AFAICS. There are also difficulties in semantics, since when
we have OLD and NEW at row level we know we are discussing the same
row. With sets of OLD and NEW we'd need to be able to link the
relations back together somehow, which couldn't be done by PK since
that could change. So we'd need to invent some semantics for a
"linking identifier" of some description. Which once we've done it
would be used by people to join them back together again, which is
what we already had in the first place. So my take is that it sounds
expressive, but definitely not performant.

Since my objective is performance, not standards, I don't see a reason
to work on that, yet. I might have time to work on it later, lets see.

--
  Simon Riggs http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 18 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 8, '13 at 9:00p
activeJun 18, '13 at 8:06a
posts18
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase