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