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.

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.

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.

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.
Yo dejaria que el SQL Server decidiera.

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.

Por partes, no sé a que se refería tu entrevistador pero podría ser.

Hay ciertos joins en los que el optimizador puede decidir crear una tabla de
claves hash para conseguir ejecutar la consulta, generalmente cuando las
tablas en las que se está trabajando no tienen un índice por el campo
deseado o son subquerys y esas cosas.
Otra cosa distinta es que uses para búsqueda de literales un checksum para
obtener un índice más chico. Es decir, Si tienes un campo descripción de 40
caracteres, y buscas una dirección concreta,(por ejemplo paises, o cosas
así), puedes pensar crear un campo que sea el checksum del nombre, y cuando
ejecutes busquedas elegir aquellos que el checksum coincida, de acuerdo que
pueden salir elementos 'no deseados', pero con 40 caractres caben unas 200
claves por página con un entero unas 2000, es decir tus búsquedas pueden
resultar hasta casi 10 veces más rápidas si el índice es usado.


=Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP.
Brigada Anti-Cursores
Aviso de Seguridad
http://www.microsoft.com/spain/tech...9-USER.asp
==
"Mauricio Sthandier R." <mauricio@@sthandier.net> escribió en el mensaje
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.