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

Re: Effects of cascading references in foreign keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>,Martin Lesser <ml-pgsql(at)bettercom(dot)de>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Effects of cascading references in foreign keys
Date: 2005-10-29 18:01:58
Message-ID: 11904.1130608918@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Sat, Oct 29, 2005 at 09:49:47AM -0500, Bruno Wolff III wrote:
>> It looks like this feature was added last May, so I think it only applies
>> to 8.1.

> Earlier versions appear to have at least some kind of optimization.

Yeah.  IIRC, for quite some time we've had tests inside the FK update
triggers to not bother to search the other table if the key value hasn't
changed.  What we did in 8.1 was to push that test further upstream, so
that the trigger event isn't even queued if the key value hasn't
changed.  (This is why you don't see the trigger shown as being called
even once.)

Looking at this, I wonder if there isn't a bug or at least an
inefficiency in 8.1.  The KeysEqual short circuit tests are still there
in ri_triggers.c; aren't they now redundant with the test in triggers.c?
And don't they need to account for the special case mentioned in the
comment in triggers.c, that the RI check must still be done if we are
looking at a row updated by the same transaction that created it?

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2005-10-29 18:35:25
Subject: Re: Effects of cascading references in foreign keys
Previous:From: Bruce MomjianDate: 2005-10-29 16:19:14
Subject: Re: Effects of cascading references in foreign keys

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