Problema de optimizacon tabla grande

[webness]

HOLA TENGO UNA TABLA CON APROXIMADAMENTE UNOS 120.000 REGISTROS Y CON 92 CAMPOS.

NECESITO HACER ESTE QUERY

Código SQL:

SELECT    sp.ciudad,sp.nombre_localidad AS localidad,
                sp.periodo,
                sp.nivsocio,
                to_char(SUM(sp.htotal),'999g999g999') AS htotal,
                to_char(SUM(sp.h0509),'999g999g999') AS h0509,
                to_char(SUM(sp.h1014),'999g999g999') AS h1014  
FROM       servcon_poblaingas_76001 sp  
WHERE    sp.codigo_localidad IN ('10') AND 
                sp.periodo IN ('2007','2008','2009') AND 
                sp.nivsocio IN ('3','4') 
GROUP BY sp.ciudad,localidad,sp.periodo,sp.nivsocio 
ORDER BY localidad,periodo,nivsocio
 

la primera ves que lo lance hiban mas de 3 minutos y nada que terminaba, le puse un indice

Código SQL:

CREATE INDEX idx_localidad_periodo_nivsocio ON servcon_poblaingas_76001 USING btree(codigo_localidad, periodo, nivsocio);
 

que se creo rapidamente y volvi a lanzar el query y se seguio demorando, despues quitando el indice me demore mas de 10 minutos.

Ensaye el query pero sin las sumas y se demoro maximo 96 milisegundos.

mi pregunta puntual es: como puedo obtimizar este query para que las sumas y los indices sea mas prudencial el tiempo de ejecucion.

[webness]

BUENO, LE PREGUNTE PREGUNTE A UNA COMPAÑERITA MUY PRESIOSA ELLA ACA EN LA OFICINA Y ME DIJO QUE COLOCARA EL INDICE APENAS CON EL CAMPO codigo_localidad Y SE DEMORO TAN SOLO 96 milisegundos.

DE TODOS MODOS me gustaria saber del porque con el indice compuesto fue tan terrible la busqueda.

[huesos52]

describe como tenías los campos indexados.
Eran llaves primarias?
La totalidad de los registros se repetian muchas veces con los campos indexados?

Con un poco mas de detalles podemos ver que puede estar pasando.

saludos amigo webness

[webness]

la tabla como tal no tiene una llave primaria puesto que no es una tabla transaccional sino una tabla de consultas historicas, entonces estoy garantizando primero que la informacion que poseo alli es unica para cada registro, segundo no tengo claves foraneas debido a la gran cantidad de datos, no me interesa hacer join con otras tablas.

No todos los registros estan repetidos todos son diferentes, pero la combinacion de algunos de sus valores si estan repetidos puesto que encontramos valores de rangos de poblacion por edad, estrato, localidad,barrio, ciudad, todo esto por periodos (años), es decir que puedo tener un registro que indique que en bogota, para el barrio x de la localidad y para el estrato 4 hay un total de 56 mujeres de 20 a 24 años y asi encontramos registros para 15 años, de todos los barrios, de todas las localidades, con todos los estratos..... etc.

Espero haber sido claro acerca de la finalidad de la tabla.

[huesos52]

Por lo que decías en tu segundo post y la recomendación que te dió tu compañera (Muy buena), me hace pensar que los elementos indexados tienen muchos registros repetidos por lo que estos campos no son recomendables para el uso de indices.

El espacio y recursos que consume un indice es bastante y se debe hacer con un analisis previo de lo que se quiere lograr y si su uso va a ser reflejado positivamente en el rendimiento de la BD.

En pocas palabras, un indice se comporta como el indice real de un libro. Si uno va al indice de un libro y busca por palabra clave (Y solo hay una, o pocas), va a ser mucho mas fácil encontrar la pagina y la ubicación de lo que estamos buscando. Pero si en el indice, hay 500 repeticiones de la palabra clave, tendremos que hacer la búsqueda en 500 paginas para mirar cual es la pagina puntual que necesitamos.

SI viste un gran incremento en el rendimiento cuando pusiste el indice de solo el campo codigo_localidad muy seguramente este código se repite pocas veces (o una sola) en la
tabla y la búsqueda es optima. Pero al tener un indice compuesto que se puedan presentar muchas repeticiones, la búsqueda se puede tornar bastante lenta.

Saludos webness