| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Virginia <mavir78(at)gmail(dot)com> |
| Cc: | JHONATAN CANO FURAGARO <jhonatan(dot)cano(dot)f(at)gmail(dot)com>, Guillermo Villanueva <guillermovil(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
| Subject: | Re: problema con trigger |
| Date: | 2010-10-27 13:25:47 |
| Message-ID: | 1288185793-sup-5543@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-es-ayuda |
Excerpts from Virginia's message of mié oct 27 10:04:57 -0300 2010:
> Creo que el campo si debe ser incluído en la tabla pues al momento de
> manipular búsquedas o cualquier cosa por el campo total es más rápido que
> tener q realizar las ponderaciones y sumas al momento de buscar.
¿Consideraste el hecho de que tener el campo almacenado hace que el
registro sea más grande y por lo tanto el uso de I/O es mayor, y el uso
de caché es menos efectivo? El que se hagan más operaciones de CPU no
implica necesariamente que sea más rápido, sólo lo sabrías midiendo
ambas cosas. Sobre todo hay que tener en cuenta que generalmente los
servidores de BD están sobredimensionados en CPU y cortos en ancho de
banda de I/O. Si las CPUs pasan ociosas 24 horas al día, ¿qué sentido
tiene quitarles trabajo para dárselo a los discos, que pasan saturados
todo el día?
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2010-10-27 13:39:40 | Re: Error en funcion SOLUCIONADO |
| Previous Message | Jaime Casanova | 2010-10-27 13:25:46 | Re: problema con trigger |