Re: Problema de Performance

2008/1/24, Yasset Perez Riverol <yasset(dot)perez(at)biocomp(dot)cigb(dot)edu(dot)cu>:
>
> Hola a todos :
> Estoy Construvyendo una aplicacion en java que se conecta a una base
> de
> datos en postgresql, el problema es el siguiente:
> Mi disehno relacional es este:
>
> Tabla 1
> atributo a (key)
> atributo b
> atributo c
>
> Tabla 2
> atributo a (key)
> atributo b
>
> Table 3
> atributo a (forein key the a Tabla 1)
> atributo b (Forein Key the a Tabla 2)
>
> hago un query de la forma
> select tabla1.a, tabla1.b, tabla1.c, tabla2.b
> from tabla1
> inner join tabla3 on (tabla1.a = tabla3.a)
> inner join tabla2 on (tabla3.b = tabla2.a)
>
> Ahora bien el query se demora alrededor de 10 min porque tengo 5 millones
> de
> records en a tabla 1 y 9 millones en la tabla de relacion 3.
>
> Alguna idea de como bajar este tiempo. (Maquina Dual AMD Athlon 2.4, 3 GB)
>
> Sldos Yasset
> --
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envía "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>

SOLUCIÓN:
El inconveniente no estaba en el query en sí, ni en los tipos de datos, sino
en el contenido del campo id_tabla1 que se está usando para el join.
Según Yasset, este campo es del tipo VARCHAR, y tiene la forma XXXXNNNNNNNN.
Donde XXXX es un código alfabético y NNNNNNNN es un numérico rellenado con
ceros.
El problema radica en que la dispersión de los datos del parcial XXXX es
bajísima, y si adicionamos los ceros a la izquierda, nos encontramos que los
primeros 6 u 7 bytes de la clave es prácticamente la misma para los 5
millones de registros. Por esto, el motor decide no tener en cuenta estos
índices antes de devolver resultados.

Para salvar este inconveniente, se le agregó a la tabla3 y a la tabla1 un
campo del tipo int con el valor NNNNNNNN con sus respectivos índices. Ambos
índices quedaron con una gran dispersión (no poseo la información, pero
supongo que está en el orden del 95% o más) y se reescribió el query para
usar este campo como join.

El resultado fue que en este caso el motor decide utilizar los índices,
logrando bajar de 10 a 2 minutos el resultado de la consulta.

Habitualmente, me he encontrado con problemas de dispersión de este tipo en
índices, pero siempre en combinados (con más de un campo), donde el primer
campo tiene muy poca variabilidad, y siempre lo he solucionado invirtiendo
el orden de los campos en la declaración del índice.

TIP 999: Un índice con baja dispersión, es ocupar espacio inútilmente!

Saludos,
Silvio

--
Silvio Quadri