Si haces un explain de una reunión entre esas dos tablas, qué dice? El 9 de febrero de 2017, 20:12, jvenegasperu . <jvenegasp...@gmail.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" <guillermo...@gmail.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 . <jvenegasp...@gmail.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 . <jvenegasp...@gmail.com> >>> escribió: >>> >>>> Hola jaime >>>> buenas tardes >>>> >>>> El 6 de febrero de 2017, 13:27, Jaime Casanova < >>>> jaime.casan...@2ndquadrant.com> escribió: >>>> >>>>> 2017-02-04 12:34 GMT-05:00 jvenegasperu . <jvenegasp...@gmail.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 >>>> <jvenegasp...@gmail.com> >>>> >>> >>> >>> >>> -- >>> José Mercedes Venegas Acevedo >>> cel Mov RPC 964185205 >>> >>> skype jvenegasperu >>> facebook jvenegasperu >>> <jvenegasp...@gmail.com> >>> >> >>
