On Thu, 26 May 2005, Stephan Szabo wrote: > On Fri, 27 May 2005, Neil Conway wrote: > > > Stephan Szabo wrote: > > > Are you sure? RI_FKey_Check seems to have a section on > > > TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the > > > old row wasn't part of this transaction. > > > > Well, regardless of how RI_FKey_Check() itself works, ISTM there is no > > need to enqueue the RI trigger in the first place. That's when the > > update-on-PK-table optimization is applied -- see trigger.c circa 3005. > > The specific case I was looking at resulted in the postgres backend > > allocating a few hundred MB just to store all the pending RI triggers, > > even though the UPDATE in question didn't change the foreign key field, > > so it didn't matter a great deal how quickly RI_FKey_Check() was able to > > bail out. > > Okay, I can't think of cases even with triggers and the like where > removing the check on equal valued rows would give appreciably different > results, but I haven't thought too hard about it.
Err, except the case that Tom mentions in his message. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly