Tablas Hash (Temporales)

Si tuvieras una maquina MPP como cuando tienes TERADATA las estrategias para
distribuir los queries enplean un hash perfecto y funcionan muy bien como
mecanismo de balanceo de carga en los distintos procesadores (reales o
virtuales). En el caso del SQL Server el hash que genera tambien es perfecto
pero no tienes una maquina MPP sino SMP y su objetivo primario no es el
balanceo de la carga.

Son utiles en el armado y gestion de resultados intermedios en consultas
complejas donde los resultados no se encuentran ordenados y si utilizas otra
estrategia de join (que no fuera hash join) requeriria precisamente un orden
en al menos uno de los conjuntos.

Sin embargo su principal problema es que debe existir al menos una condicion
por igualdad en el join ya que al ser una funcion de aleatorizacion esta
impide que puedas usar otro tipo de operador. El resto de las condiciones
puedes ser predicados aplicados como residuos

Otro uso de los hash en eñ SQL Server son los "group by" y por eso no hay
garantia de que los group by aparezcan ordenados.

Ante esa pregunta yo hubiera preguntado a que se refiere con hash tables.

En el caso de tablas temporales le habria respondido que ni loco porque el
SQL Server seguramente con las estadisticas actualizadas y un query como el
indicado, con una clausula where "normal", pero en definitiva trivial,
obtendria un plan mucho mejor que el que yo pudiera forzar. Si el SQL Server
encontraba que era mejor usar tablas temporales, seguramente usaria
operadores del tipo TABLE SPOOL.

Jose Mariano Alvarez
Comunidad de base de datos
Grupo de Usuarios Microsoft
www.mug.org.ar



"Mauricio Sthandier R." <mauricio@@sthandier.net> wrote in message
news:esOcTc%

Fui a una entrevista en inglés y el entrevistador me dijo que si ante una
consulta así :

SELECT * FROM tabla1 INNER JOIN tabla2... tabla6

y que tomaba 5 a 6 minutos yo usaría Hash Tables... luego cambió la

pregunta

a Temporary Tables.

Estuve investigando y encontré Hash Indexes, en que para una clave

compleja

puedo almacenar el checksum de lo que me interesaría ocupar en el join.

Esta

técnica sería sensiblemente más rápida.

Pero pienso que así opera naturalmente SQL Server al crear los índices y
sabrá ocupar el que necesite sin forzarlo con una Hash join hint. Además
existe la posiblidad de que un checksum se repita para una clave distinta.

En fin.. alguien tiene idea de a qué se refería ?
Los índices se almacenan de una sola forma ?

Fear
is temporary.
Pride
is forever.