Stephan Szabo <sszabo@xxxxxxxxxxxxxxxxxxxxx> writes:
> On Mon, 18 Feb 2008, Tom Lane wrote:
>> but right offhand I see no reason for it to do so --- it doesn't
>> *do* anything with fk_rel except close it again. Likewise
>> RI_FKey_keyequal_upd_fk doesn't seem to really need to touch the
>> pk_rel. Is there something I'm missing in that? Maybe this is
>> a vestige of earlier coding that did need to touch both rels
>> to perform the keysequal check?
> Probably something like that - maybe ri_BuildQueryKeyFull might have
> needed it open.
Yeah, looking back at 8.2 and earlier confirms this --- it used to need
access to the rel in order to interpret the trigger arguments
(specifically, convert column names to numbers). In the 8.3 rewrite
that got rid of the trigger arguments, I removed the no-longer-needed
Relation arguments to ri_BuildQueryKeyFull, but didn't take the next
step of not opening the relation where it wasn't being used otherwise.
I was thinking there might be some arcane locking reason for transiently
locking the other table, but I can't imagine what it would be. We have
a writer's lock on the table we are modifying, and that is sufficient to
ensure that the RI constraint isn't changing, so ...
> Actually, I'm wondering if the ri_BuildQueryKeyFull call
> is also unnecessary now - I don't think we ever use the qkey that comes
> out of it unless I'm missing some code.
Good point --- ri_KeysEqual only needs the RI_ConstraintInfo not the
qkey. In 8.2 and before it used the qkey to get the info.
In short, this is easy to improve in HEAD and 8.3, but not so readily
fixable in prior releases. I'll go make it so.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
