Resolver cualquier problema de desempeño empieza siempre por averiguar *exactamente* donde esta el problema. No es cosa de adivinar y ver que sale.
Luego en medir como estan las cosas:
http://wiki.postgresql.org/wiki/Using_EXPLAIN
Luego esta en revisar si la forma de atacar el problema es correcta, y de ser posible, simplificar y simplificar. Por regla general, el mayor avance se logra en este punto.
Luego esta en usar la herramienta/tecnica adecuada para la situacion. Por regla general, la mayor eficacia se logra en este punto.
Luego en volver a medir y ver si se arreglo el asunto.
Por ultimo (a menos que las pesquizas den lo contrario) esta en hacer ajustes de hardware. Lo que implica saber exactamente como usa el hardware el software en question. Por ejemplo, muchos se fijan solo en lo rapido de su CPU, y no en el I/O ni en la memoria. Otros no piensan en los valores de cache, ni en como usar las conexiones, ni muchos otros factores.
P.D: Una cosa que quiero recalcar, que pense al leer:
Cita:
|
A manera de ejemplo inserte por medio de ciclos 600.000.000 de registros que serian los movimientos de un mes
|
A veces los problemas surgen porque uno se aferra a hacer las cosas de una manera, y luego espera que salgan de otra (meter un cuadrado dentro de un circulo). Es mejor preguntarse: Es realmente necesario lo que estoy haciendo? Porque estoy metido en este lio? Porque estoy aferrado a como son las cosas *ahora*? SI tengo el poder, que puedo hacer para cambiar el problema hasta que sea algo trivial de resolver?
Un ejemplo, de hace años cuando hacia un software de calificacion de colegios, era que generar los reportes con las notas y editar las notas era un trabajo complicado, lento y lleno de errores y casos especiales. Un dia, viendo el formato que se usa para hacer eso a mano, pense: "Porque no mejor haga la tabla *exactamente* como se ve aqui impreso? -en vez de seguir con las tablas normalizadas tal como siempre ha sido-" Y !puff! empezo todo a salir bien
