Re: Optimizacion de select(pregunta de novato)

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 <refreegrata(at)yahoo(dot)com>

> 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 <alvherre(at)alvh(dot)no-ip(dot)org>* wrote:
>
>
> From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>
> Subject: Re: [pgsql-es-ayuda] Optimizacion de select(pregunta de novato)
> To: "uno dos" <refreegrata(at)yahoo(dot)com>
> Cc: "Alejandro D. Burne" <alejandro(dot)dburne(at)gmail(dot)com>, "pgsql-es-ayuda" <
> pgsql-es-ayuda(at)postgresql(dot)org>
> 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