Re: [pgsql-es-ayuda] Duración update

Hola,
gracias por la respuesta.
He aumentado los checkpoint segments a 32, el mantenance work memory, el shared buffers effective cache ...
y he conseguido reducir el tiempo a la mitad. El autovacuum ahora se lanza al finalizar la query no por el medio, aunque no como antes pero aún le cuesta bastante se tira 3 o 4 minutos ???

Tienes razón las pruebas son sobre equipo justito, ya que a partir de ahí sólo podemos mejorar.

Una cosa que he descubierto es que la query updatea todos los registros, el planner internamente no mira si el campo ya es nulo y se evita el trabajo ???

Haciendo el mismo update y añadiendo al final 'and pc_d5c is not null' tarda menos de 2 segundos ya que sólo habían 5800 registros con valores. Mientras que sin este and... ahora tarda sobre 125000 ms.

Lo de los número de registros no lo entiendo cómo ha podido pasar, después de haber creado la bd e importado los datos le lanzo un vacuum analyze sobre la bd. Y después sobre esta tabla de clientes si he hecho bastantes selects, pero updates muy pocos y sobre una cantidad reducida de registros.

Los parámetros cost delay no los he mirado, soy novato haber si les puedo pegar una hojeada. De momento ya descubrí en una anterior consulta el poder de los índices compuestos en postgresql, que del mundo desde el que vengo no eran nada efectivos y no estaba acostumbrado a ellos.

Saludos y gracias.

________________________________
De: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Para: FRANCISCO JOSE PALAO VILLANUEVA <fjpv_2000(at)yahoo(dot)es>
CC: "pgsql-es-ayuda(at)postgresql(dot)org" <pgsql-es-ayuda(at)postgresql(dot)org>
Enviado: Lunes 14 de abril de 2014 16:24
Asunto: Re: [pgsql-es-ayuda] Duración update

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 (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda