Re: Problemas con PostgreSQL 9.1.2

Hola Jaime, disculpa la tardanza.. ando corriendo haciendo pruebas y
mas.. en cuanto a tus preguntas:

puedes mostrar el trigger?
esta muy grande ( tal vez tambien sea por ahi el problema ), te
explico y si lo requieres con gusto te lo adjunto en un archivo

>> dejarnos ver algo que nos de una idea de
>>que podria ser?cuando dices que se queda trabado y que el statement_timeout lo mata,
>>quiza las consultas dentro del trigger estan muy lentas?

Segun lo que encontre es un select con un limit 1... normalmente y en
el psql esta consulta tarda 100ms exageradamente pero dentro de
plpgsql tarda mas de 5 min, te paso el log:

ERROR: canceling statement due to statement timeout
2011-12-23 03:20:58 UTC : pgsql(at)216(dot)24(dot)251(dot)210 motumweb :CONTEXT: SQL
statement "select point_geom, fechacreacion,
importacionid, odometrototal from datosentrada_his where viajeactivo =
p_viajesis and entrandosaliendo=1 order by importacionid limit 1"

aqui la consideracion mas importante es que la tabla
"datosentrada_his" es una tabla con unas 50 columnas ( se que debo
normalizarla, pero me esta costando trabajo por todo lo ya
desarrollado) la cual tiene unos 80 millones de registros, debido a
eso se particiono, y como los datos se ingresan cada seg aprox.
entonces particione por semana donde obtengo particiones de 2.5
millones de registros por particion ( me gustaria saber si es
demasiado cada semana segun tu opinion), ahorita tengo unas 18
particiones, 15 llenas, la actual y 2 mas para las proximas semanas.
Creo que por aqui el planeador de consultas de postgresql 9.1 esta
haciendo algo raro con respecto al 8.4; ya intente meter en la
consulta la fecha dentro del where pero no ayudo ( esto debido a que
mi particion la hago por fechas) , estoy buscando a ver si despues de
que se termina cada parcition puedo agregar algun check para que
tambien tome encuentra otras columnas que uso para busqueda de
informacion como el "importacionid" que lo ves en la consulta y el
"viajeactivo" tambien mostrado en la consulta del log. Por desgracia
no puedo hacer estos check antes por que no se en que numeros
empezaran dentro de cada particion y tampoco en cuales terminaran.

Otra consideración es que tengo un trigger de 2500 lineas... no se
ejecutan todas cada vez.. esta partido en 4 dependiendo de como llegue
la información es lo que se va hacer.. estoy trabajando en conjunto
con los programadores para eliminar lineas de este trigger que pueden
afectar el desempeño.. pero por el momento solo pegan en cierto casos
espcificos que casi no suceden.

>> has ejecutado
>>VACUUM ANALYZE?

Si en este servidor recien desplege el respaldo se hizo un vacuum
analyze, despues de checar algunas pruebas hice otro... y normalmente
en produccion tengo un cron que hace todas las noches el vacuum
analyze.

>>Tienen por casualidad tus tablas columnas INET con indices asociados?

Rafael
en cuanto a tu pregunta no tengo ninguna columa INET.. si tienes
alguna otra idea es bien recibida. Gracias

Bueno gracias a todos y espero puedan darme mas ideas de donde buscar. Saluds

Roberto Campos