FRANCISCO JOSE PALAO VILLANUEVA escribió: > Hola, > tengo un update p_c set pc_d5c=null where pbv_id between 803 and 809. > > El campo pc_d5c varchar(2) no está indexado. > El campo pbv_id si está indexado. > La tabla tienen 474818 registros > el analyze me muestra: > > Update on p_c (cost=0.00..50294.05 rows=606470 width=355) > -> Seq Scan on p_c (cost=0.00..50294.05 rows=606470 width=355) > Filter: ((pbv_id >= 803) AND (pbv_id <= 999)) > > Cuando la lanzo me ha tardado 212207 ms.
Vamos a ver, ¿tu tabla tiene 474k registros, pero el update estima que la condición "pbv_id >= 803 AND pbv_id <= 999" coincide con 606k registros? Claramente algo está mal ahí. ¿No será que necesitas un ANALYZE antes de hacer ese update? > Hacia la mitad del tiempo se lanza autovacuum sobre la tabla p_c y > tarda un montón de tiempo en terminar, después incluso de que la > consulta terminó (vamos que pensaba que se había quedado colgado). Si > lanzo el vacuum analyze desde pgadmin, mata al autovacuum y termina en > 102165 ms. autovacuum se toma las cosas con más calma para no saturar el sistema. Mira los parámetros relacionados con "cost delay". También asegúrate de poner un maintenance_work_mem razonable. Un valor bajo hace que vacuum tarde mucho porque tiene que recorrer índices múltiples veces. > Aparecen varios mensajes de aumentar checkpoints segments en el log, > por lo que cambié los valores a: > > checkpoint_segments=5 y checkpoint_warning = 60s, con lo que me > aparecen bastantes menos. Ya veo, ¿estás corriendo el servidor en un teléfono algo antiguo? Considera un servidorcito algo más capaz. (Consejo: deberías aumentar checkpoint_segments bastante más que eso, y checkpoint_timeout posiblemente también). -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
