Eduardo, muchas gracias por tu respuesta: Voy a hacer una revision exhaustiva de lo que me indicas, los índices que usamos en su mayoría son Btree, y utilizamos GisT para los geográficos, nada complejo, sin índices compuestos. No hacemos modificaciones sobre las tablas de fecha heredadas, pero debido a la gran cantidad de transacciones siempre hacemos un vacuum para evitar el wraparound. Comentaré los resultados de estos análisis que me mencionas. desde ya muchisimas gracias por la información a todos.
Saludos Mario. On Tue, 20 Jul 2010 01:42:29 +0200, Eduardo <emor...@xroff.net> wrote: > On Mon, 19 Jul 2010 18:44:16 -0300 > <msile...@easymail.net.ar> wrote: > >> Alvaro, gracias por tu respuesta: >> Las actividades de los clientes están limitadas a lo que nosotros >> montamos en la página web, por otro lado, los inserts por minuto que >> menciono están dados por equipos que transmiten desde vehÃculos, >> por lo que la parte cliente en caso que estén arruinándolo, la >> culpa seguirÃa siendo nuestra. Hemos optimizado hasta donde pudimos >> el postgres para dar lugar a las consultas que se realizan, pero >> apartentemente puede que estemos errados en alguna consulta al inicio >> de sesión que nos produce el problema planteado en la hora pico de >> la mañana. >> >> Saludos y gracias >> >> Mario . >> > > Puede que actualizar los indices al hacer los updates te este dando > problemas. ¿Como los creaste? Algunas ideas que se me ocurren son: > > a) Probar a bajar el FILLFACTOR a la mitad, 45 o incluso 30, de todos > los indices btree. > b) ¿Que indices estas usando realmente y necesitas alguno mas? > > Con pgadmin yo hago lo siguiente (para tablas con gran numero de filas): > > b1) Voy a la tabla y pido sus estadisticas en la pestaña de la derecha. > b2) Si el numero de barridos secuenciales es muy alto es que me falta > algun indice. > b3) Voy, dentro de la tabla, a la seccion de los indices y saco las > estadisticas de cada uno. > b4) Si el valor de busqueda por indices es muy bajo o cero, el indice no > me sirve de nada o casi nada y lo elimino. > b5) Si el valor es muy alto, el indice esta bien. > > Cuando me falta algun indice creo uno por columna y despues de unos > dias miro cual se usa y cual no. Elimino los que no. > > c) Igual el tipo de indice que usas no es el correcto. Puede > que necesites uno de tipo hash para algunos indices (aunque no es tan > versatil como un btree) > > d) Usas la version 8.2.x Sube a la version 8.3 como minimo para poder > hacer CLUSTER sobre un indice, por ejemplo el de fecha a las tablas. > e) ¿Las tablas de meses anteriores modifican sus datos? ¿Necesitas > realmente hacer un VACUUM a dichas tablas cada noche? > f) Has comentado que haces un TRUNCATE TABLE, acuerdate de hacer un > REINDEX de la tabla despues. > > Sobre tu pregunta de TRUNCATE, en el manual de 8.4 (supongo que > aplicable a la 8.2) vienen 2 warnings, el primero de los cuales creo que > es aplicable a tu caso: > > TRUNCATE is not MVCC-safe (see Chapter 13 for general information about > MVCC). After truncation, the table will appear empty to all concurrent > transactions, even if they are using a snapshot taken before the > truncation occurred. This will only be an issue for a transaction that > did not access the truncated table before the truncation happened — any > transaction that has done so would hold at least an ACCESS SHARE lock, > which would block TRUNCATE until that transaction completes. So > truncation will not cause any apparent inconsistency in the table > contents for successive queries on the same table, but it could cause > visible inconsistency between the contents of the truncated table and > other tables in the database. > > Corregidme si me equivoco, viene a ser que si alguna otra transaccion > de escritura empieza durante el truncate, esta bloquea el truncate > hasta que termina. > > > P.S. Antes de que nadie diga nada y me tire un monton de bits > sucios a la cabeza, lo que hago para saber que indices uso y cuales no > de esta manera es por que la aplicacion que desarrollamos usa hibernate > por medio, el cual es un oscuro pozo que no se sabe como funciona... y > no crea ningun indice. > > HTH > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) > Para cambiar tu suscripci�n: > http://www.postgresql.org/mailpref/pgsql-es-ayudaEd - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
