On Tue, 2007-04-17 at 17:16 -0400, Tom Lane wrote: > A recent discussion led me to the idea that FK triggers are fired > unnecessarily during an UPDATE if the foreign-key column(s) contain > any NULLs, because ri_KeysEqual() treats two nulls as unequal, > and therefore we conclude the row has changed when it has not.
FK trigger *can be optimised away* is true. No need to have a discussion about whether NULL == NULL, but the critical test is: if I overwrote it, would you be able to tell? The answer is No, so away it goes. > I claim that both ri_KeysEqual() and ri_OneKeyEqual() could consider > two nulls to be equal. Furthermore it seems like ri_AllKeysUnequal() > should do so too; the case can't arise at the moment because the sole > caller already knows that one of the key sets contains no nulls, but > if this weren't so, the optimization would be actively wrong if we > concluded that two nulls were unequal. > > Comments? > > Also, I am wondering to what extent the ri_KeysEqual() calls in > ri_triggers.c are redundant, given that commands/trigger.c now has > the smarts to not even queue the trigger when those cases apply. Would be good to document that behaviour in ri_triggers.c - I was completely misled when I looked at the code a while back. Probably more than one thing can go. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings