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