De casualidad reviaste lo que te mensionaron de los FK (ForeingKey). La razon es simple, cuando haces un insert y ese esta asociado a una llave foranea (el motor revisa que este el valor referenciado) si no tiene indice el FK se hace un full scan. a mas registros mas IO. Esta bien que la CPU este a un 100% si estas procesando indices, pero revisa que ese 100% efectivamente este con indices, revisa el IO con iostat -m -x 2 /dev/sd?
Ahora si un proceso esta lento mi olfato me dice que te vayas a revisar el codigo especialmente si tienes un update por ahi, y revisa el where de ese update (puede ser que te falte una condicion estes haciendo un update a toda una tabla)... pero es especulacion sin mayor informacion :( ... 2010/5/15 uno dos <[email protected]> > Bueno. en efecto, yo creo que tanto el código de la aplicación, así como > el diseño de la base de datos pueden ser optimizados, es por eso que lo > estoy revisando con gran detalle, sin embargo, he notado que el rendimiento > ha disminuido inclusive en secciones, en donde realizo consultas tan > simples, como un INSERT, sin pasar por triggers, ni nada. > > Para el trigger, mi plan es reducir el tamaño de la tabla, pasando > registros mas viejos a una nueva tabla reduciendo así, el número de > registros, que son constatemente usados de 22000 a 2000. Aunque claro, > debiera crear un trigger before y otro after para la misma tabla. Debo > decir, que nunca he creado 2 triggers para una misma tabla, pero, no creo > que postgres se resienta. > > > Saludos, y gracias por responder. > > --- On *Fri, 5/14/10, Alvaro Herrera <[email protected]>* wrote: > > > From: Alvaro Herrera <[email protected]> > > Subject: Re: [pgsql-es-ayuda] Optimizacion de select(pregunta de novato) > To: "uno dos" <[email protected]> > Cc: "Alejandro D. Burne" <[email protected]>, "pgsql-es-ayuda" < > [email protected]> > Date: Friday, May 14, 2010, 10:22 PM > > > Excerpts from uno dos's message of vie may 14 22:15:57 -0400 2010: > > Ok, el autovacuum cada 1 minuto lo configuró el encargado(yo sólo estoy a > cargo del código). Según él, leyó en la documentación que este era el tiempo > recomendado. > > Sí, creo que fue eso lo que escribí en la documentación. El chequeo es > muy barato de ejecutar, así que no es problema ejecutarlo muy > frecuentemente siempre que los parámetros que determinan cuándo lanzar > un vacuum o un analyze sean apropiados. Si no han cambiado mucho los > parámetros de autovacuum, es difícil que esté en un estado muy malo. > > > Con respecto al trigger, no es tan grande, pero resulta que es un > documento del tipo egreso, que tiene n-líneas. cada línea es una fila en la > tabla, y por cada línea se ejecuta un trigger before. Yo creo que esta bien, > ya que cada línea comprueba el stock, ya que cada línea representa a un > producto en particular, pero como pueden haber egresos con unas 100 líneas, > la comprobación por cada una, aunque necesaria, puede hacer bastante lento > el proceso. > > Es posible que tu trigger sea mucho más ineficiente de lo que podría > ser. > > -- > > > -- Saludos, Horacio Miranda Aguilera. RedHat Certified Engineer DBA Oracle - Large databases +56 2 8974500
