Re: Cuantos locks son muchos locks?

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 <emorras(at)xroff(dot)net> wrote:
> On Mon, 19 Jul 2010 18:44:16 -0300
> <msileone(at)easymail(dot)net(dot)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(at)postgresql(dot)org)
> Para cambiar tu suscripci�n:
> http://www.postgresql.org/mailpref/pgsql-es-ayudaEd