Re: update masivo con minimos recursos

Si haces un explain de una reunión entre esas dos tablas, qué dice?

El 9 de febrero de 2017, 20:12, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
escribió:

> 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>
>>>
>>
>>