Demora para borrar indice

[webness]

, HELLO EVERYBODY, bueno la cuestion es esta, cree un indice de un solo campo sobre una tabla de 11 campos y 150mil registros, lo hizo en menos de un minuto, ahora lo estoy borrando y lleva mas de 5 minutos.

¿quisiera saber a que se debe esto, y como puedo hacer a futuro para optimizar la velocidad de respuesta?

[huesos52]

¿quisiera saber a que se debe esto

Ni idea.

y como puedo hacer a futuro para optimizar la velocidad de respuesta?

Mira lo que dice la documentación oficial

For most index methods, the speed of creating an index is dependent on the setting of maintenance_work_mem. Larger values will reduce the time needed for index creation, so long as you don't make it larger than the amount of memory really available, which would drive the machine into swapping. For hash indexes, the value of effective_cache_size is also relevant to index creation time: PostgreSQL will use one of two different hash index creation methods depending on whether the estimated index size is more or less than effective_cache_size. For best results, make sure that this parameter is also set to something reflective of available memory, and be careful that the sum of maintenance_work_mem and effective_cache_size is less than the machine's RAM less whatever space is needed by other programs.

Tomado de la documentación oficial de PostgreSQL

Estas variables que mencionan son las encargadas de agilizar el mantenimiento de los indices. Podrías jugar con ellas y comparar resultados.

Sin embargo... No debe preocuparte si se demora o no el borrado de un indice, ya que esta es una tarea que se realiza una sola vez. El mismo indice se actualiza cada que encuentra cambios en la tabla por lo que no es necesario estar borrandolo y creandolo en diferentes ocasiones.

[webness]

es que necesito borrar el indice porque no me sirvio para nada, antes me empeoro la situacion porque estaba haciendo unos query y ahora estan peor de lentos.

Bueno, ahora me dicen aca que debo hacerle primero un vacum y un reindex a la tabla antes de crear y borrar los indices, que no podemos modificar los valores de estas variables por que es nada mas y nada menos que la base de datos de produccion y hay muchos procesos y servicios que dependen de ella.

me gustaria saber mas a fondo acerca del vacum y el reindex

--->> LA RESPUESTA, en sintesis sirve como para reorganziar el espacio fisico en disco de las tablas despues de que se han realizado operaciones de borrado, por ende el reindex se utilizaria para construir nuevamente los indices que se han podido corronper despues de estas acciones... estoy en lo cierto?

[huesos52]

El vacumm si es para eso webness (Reorganizar el espacio en disco después de multiples operaciones de borrado y actualuzación), pero el vacumm no afecta ni corrompe las operaciones de los indices.

Como te decia en un post anterior, el uso de indices es delicado. Puede convertirse en un problema antes de ser una solución.

No es recomendable crear indices en tablas con campos que se repitan en muchos registros, esto no es para nada eficiente. Tampoco es recomendable crear indices en tablas que tienen inserciones, actualizaciones y borrados constantes ya que cada que se presenta un cambio en la tabla, el index se corrige automáticamente a todos los registros de la tabla. Los indices son muy buenos para situaciones en las que son tablas muy grandes pero están enfocadas a las consultas y no a operaciones DDL.

Por ejemplo... en mi caso, tengo indexados unos campos de una tabla con cerca de 3'000.000 de registros y que son vitales para la consulta. Sin embargo, cada mes hay una actividad de llenado , pero solo requiere de una reindexación mensual lo cual no afecta mucho mi performance.

Ahora bien, si tienes un flujo de datos de 30 o 40 inserciones (o eliminaciones) de registros por hora, el index para cada cambio hace un proceso de reindexación que puede afectar seriamente la performace de la base de datos.

Otro dato importante, es separar las tablas y los indices en tablespaces diferentes. Un indice es muy costoso en el procesamiento de la información y dejarle ambos trabajos a un solo tablespace puede ser fatal.

Saludos

[webness]

absolutamente todas mis tablas son meramente de consulta y sus procesos de actualizacion son entre 1 y 2 al año, de hecho ni tienen una verdadera integridad referencial, por ejemplo en el caso de las lineas telefonicas aparte del tener el codigo del barrio para poder consultar tambien tenemos el nombre, para no tener que cruzar tablas como las de telefonos de bogota con mas de 2 millones de registros con la de barrio con cerca de unos 15mil.

por ahora estoy en el caso de la consulta particular que ocasiono este post que es esta:

Código SQL:

SELECT  sp.ciudad,sp.periodo,sp.nivsocio,
    to_char(SUM(sp.total_poblacion),'999g999g999g999') AS total_poblacion,to_char(SUM(sp.h2024),'999g999g999g999') AS h2024,
    to_char(SUM(sp.m2024),'999g999g999g999') AS m2024,to_char(SUM(sp.h2529),'999g999g999g999') AS h2529,
    to_char(SUM(sp.m2529),'999g999g999g999') AS m2529,to_char(SUM(sp.h3034),'999g999g999g999') AS h3034,
    to_char(SUM(sp.m3034),'999g999g999g999') AS m3034,to_char(SUM(sp.h3539),'999g999g999g999') AS h3539,
    to_char(SUM(sp.m3539),'999g999g999g999') AS m3539,to_char(SUM(sp.h4044),'999g999g999g999') AS h4044,
    to_char(SUM(sp.m4044),'999g999g999g999') AS m4044,to_char(SUM(sp.h4549),'999g999g999g999') AS h4549,
    to_char(SUM(sp.m4549),'999g999g999g999') AS m4549,to_char(SUM(sp.h5054),'999g999g999g999') AS h5054,
    to_char(SUM(sp.m5054),'999g999g999g999') AS m5054,to_char(SUM(sp.h5559),'999g999g999g999') AS h5559,
    to_char(SUM(sp.m5559),'999g999g999g999') AS m5559
FROM servcon_poblaingas_76001 sp 
INNER JOIN servcon_manzanas_new ma ON   (ma.codgeo_manzana = sp.codigo_manzana AND
                                        circle '((-76.5307371231646,3.42790487329946),0.00901875901876)' ~ point (ma.cx,ma.cy)) 
WHERE   sp.periodo IN ('2007','2008','2009','2010') AND 
    sp.nivsocio IN ('2','3','4') 
GROUP BY sp.ciudad,sp.periodo,sp.nivsocio ORDER BY periodo,nivsocio
 

estoy añadiendole a la tabla sp los campos de las coordenadas cx,cy que actualmente estan en la tabla de manzanas, para evitar el join de la tabla sp con 145.000 registros y la de manzanas con casi 200mill.

pero si puedes observar estoy haciendo un query que obtiene todos los registros cuyas coordenadas cx, cy esten en dentro de un radio determinado.... lo cual me lleva a preguntar como ¿puedo crear un indice para estas consultas geometricas?

[Sofmundi]

Para hacer es a mi me toco fue colocar un indice a cada campo de la tabla que queria y me funciona rapido en cuestion de consulta