Re: update masivo con minimos recursos

Guillermo entonces a que podría deberse o que me faltaría configurar para
que se use el índice en el server solo tengo esas 2 tablas y estoy haciendo
pruebas

El 8 feb. 2017 20:47, "Guillermo E. Villanueva" <guillermovil(at)gmail(dot)com>
escribió:

> Perdón pero no creo que Postgres no use un índice porque no entre en RAM!!
>
> El 8 de febrero de 2017, 18:31, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
> escribió:
>
>> 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>
>>
>
>