Re: Problema de Performance

["Silvio Quadri" <silvioq(at)gmail(dot)com>]

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