Optimizacion no esperada porque?

Cordial saludo, analizando la mejor forma de actualizar un campo de una
tabla que no es parte de la llave y con un join con otra tabla,
encuentro un comportamiento que no esperaba.
Planteo el tema :
La tabla a actualizar tiene cerca de 6 millones de registros(MAESTRO),
la otra tabla tiene 500 mil registros(ENVIOS) se van a actualizar
130.000 registros
el primer update es un inner entre las dos tablas, los campos que
cruzan en el join de ENVIOS son la llave de MAESTRO no.

Para mejorar el performance de actualizacion decidí crear una tabla
llamada TEMPO con los 130.000 registros con la llave de MAESTRO y el
valor del campo de ENVIOS a actualizar en MAESTRO
Creo una restriccion de PK Clustered en TEMPO que debe ser identica a
PK de MAESTRO; asumo que de esta forma estoy realizando un join uno a
uno por PK entre TEMPO y MAESTRO, y para mi concepto deberia ser un
plan de ejecucion menos costoso y que utilizaria la PK de MAESTRO para
el recorrido de actualizacion con mayor velocidad, si miro el plan del
join
TEMPO-MAESTRO ENCUENTO:
ClusteredINdex seek con icono de paraleleismo en las dos tablas, luego
paralelismorepartition streams en las dos tablas , luego merge join con
icono de paralelismo, lugeo un icno de paralelismo y por ultimo el
posible resultado del select.


Ahora el plan de ejecucion de las tablas MAESTRO-ENVIOS que yo suponia
ser menos eficiente(xq el join por MAESTRO no eran los campos de la
PK),da el siguiente plan de ejecucion:
Clustred indexscan en ENVIOS e index seek en MAESTRO lurgo un hash
match y por ultimo el select.
El porcentaje del plan de ejecucion MAESTRO-ENVIOS es 48% el de
MAESTRO-TEMPO es 52%


Agradezco sus comentarios.

Jose Nadim Mendez M.