Re: update masivo con minimos recursos

Consultando con un amigo que tambien usa postgres creemos que postgres se
demoro porque hizo un scan secuencial ya que no pudo usar los indices ya
que estos no pudieron ser colocados en memoria porque estos eran mas
grandes que la memoria RAM esto es asi? alguien tiene idea si esto es asi?

El 6 de febrero de 2017, 15:03, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
escribió:

> Hola jaime
> buenas tardes
>
> El 6 de febrero de 2017, 13:27, Jaime Casanova <
> jaime(dot)casanova(at)2ndquadrant(dot)com> escribió:
>
>> 2017-02-04 12:34 GMT-05:00 jvenegasperu . <jvenegasperu(at)gmail(dot)com>:
>> >
>> > tengo esta consulta corriendo hace 17 horas y aun no termina
>> >
>> > update padronac
>> > set fenac = padron2006.fenac,
>> > ginstruc = padron2006.ginstruc
>> > from padron2006
>> > where padronac.dni = padron2006.dni
>> >
>>
>> Saludos,
>>
>> Como dijo Jose Maria, un índice sobre padron2006.dni es necesario. Y
>> si tienes índices en la tabla padronac sería mejor eliminarlos y luego
>> reconstruirlos (obvio que solo si se puede, es decir si puedes hacer
>> esto sin usuarios que se vean afectado por la falta de índices).
>> Tienes triggers sobre la tabla?
>>
>
> Jaime primero respondo tu pregunta no hay triggers en ninguna de los
> tablas de hecho la sentencia update es la unica que se ejecuta.
>
> Tengo que comentar tambien que la tabla padronac pesa 2 Gb y la tabla
> padron2006 pesa 3 Gb aunque tiene menos registros tiene mas campos.
>
> El computador donde se ejecuta la sentencia solo tiene 1.7 Gb de RAM y un
> solo procesador que lamentablemente no se de que velocidad porque ese dato
> no me lo da amazon.
> las sentencias se ejecutan sobre postgres 9.5.5 con sus parametros por
> defecto el work_mem esta en 4 megas y shared buffer en 256 Mb
>
> Mientras ejecutaba la consulta el monitor de windows me indicaba que aun
> tenia 280 Mb de memoria ram disponibles todo el tiempo mientras se ejecuto
> la consulta.
>
> En la tabla padron2006 el dni es clave primaria y es de tipo character
> varying de 8 y
> En la tabla padronac el dni es clave primaria y es de tipo character
> varying de 8
>
> ¿supongo ya no es necesario agregar un indice por estos campos o si?
>
> En alguna parte de la documentacion lei que seria mejor crear un indice
> con patrones pero eso era en caso se use like en este caso es el operador
> "="
>
> Jaime, Jose Maria ustedes creen que el hecho de que los campos clave
> primaria sean de tipo character varying merme el rendimiento en la
> comparación?
> Acabo de revisar y ya termino la actualizacion estos son los datos que
> tengo
>
> la tabla padronac tiene 22 millones 899 mil registros
> la tabla padron2006 tiene 16 millones 200 mil registros
>
> la actualizacion se completo en 2 dias 15 horas 29 minutos 04 segundos
>
> y se actualizaron 15,621,918 registros en la tabla padronac, entiendo que
> se tuvo que necesariamente analizar el total de registros de la tabla
> padronac uno por uno.
>
> Asi que tengo estos datos
>
> 22899000 Total de registros analizados
>
> 63.5 horas es tiempo total de duracion en la actualizacion
>
> 360614.173 Total de registros procesados por hora
>
> 6010.23622 Total de registros procesados por minuto
>
> 100.170604 Total de registros procesados por segundo.
>
> Alguien a tenido una situación similar con limitados recursos se podria
> lograr hacer esto en menos tiempo? sin aumentar los recursos de hardware?
>
> Les agradezco sus comentarios
>
>
>
>>
>> --
>> Jaime Casanova www.2ndQuadrant.com
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>
>
>
> --
> José Mercedes Venegas Acevedo
> cel Mov RPC 964185205
>
> skype jvenegasperu
> facebook jvenegasperu
> <jvenegasperu(at)gmail(dot)com>
>

--
José Mercedes Venegas Acevedo
cel Mov RPC 964185205

skype jvenegasperu
facebook jvenegasperu
<jvenegasperu(at)gmail(dot)com>