Re: Do foreign key triggers get ran even if the key's value doesn't change? - Mailing list pgsql-general

From Joe Van Dyk
Subject Re: Do foreign key triggers get ran even if the key's value doesn't change?
Date
Msg-id CACfv+pL8VeR5v6nvEd1Pm7Scd6Mit6XzdGF3WzOL1iFRfUq1jg@mail.gmail.com
Whole thread Raw
In response to Re: Do foreign key triggers get ran even if the key's value doesn't change?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Do foreign key triggers get ran even if the key's value doesn't change?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
On Wednesday, May 21, 2014, Jeff Janes <jeff.janes@gmail.com> wrote:

On Wed, May 21, 2014 at 1:11 PM, Joe Van Dyk <joe@tanga.com> wrote:
I came across http://bonesmoses.org/2014/05/14/foreign-keys-are-not-free/
which seems to indicate so.

When I run the following test script, having 50 foreign keys takes
about twice as long to do the update. Is there a reason for that?
Seems like the RI triggers wouldn't have to run on updates if the
value doesn't change.

That's kind of a question of definitions.  Perhaps the trigger itself doesn't need to run, but the code that decides whether the trigger needs to run does need to run.  Where do you draw the line around what is the trigger proper and what is just infrastructure?  

However you wish to define it, change your function so that it actually does change the key field, and see how much slower that is than the behavior where you update the row without updating the key.  
 

I was expecting that the RI update triggers would have a "when (new.key is distinct from old.key)" condition on them, which would mean that the number of referencing tables wouldn't matter. 

 
Cheers,

Jeff

pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Lock during insert statement
Next
From: Moshe Jacobson
Date:
Subject: Need pg_dump not to dump extension-created triggers