El 01/10/2010 08:58 p.m., Jaime Casanova escribió:
On Thu, Sep 30, 2010 at 1:14 PM, Eduardo Leonardo Reyes Batista
<[email protected]> wrote:
Se podría configurar un servidor de BD en postgres que el SELECT mas mal
creado del mundo no lo tumbe?
claro, pon statement_timeout en 1s (seguro que aun poniendolo en 10s
funciona); pero todas esas consultas malas se cancelaran despues de un
rato
Ojo que si pones statement_timeout en 1h seria lo mismo que nada asi
que no creas que realmente se puede, mi consejo solo va a evitar que
alcanzen a consumir muchos recursos... una sentencia mal construida
tiene que arreglarse no hay atajos
Quizá estas tratando de prevenir en el lugar equivocado, si bien la
propuesta de Jaime es la adecuada para evitar que se consuman demasiados
recursos en el servidor, quien te dice que ese sistema no va a continuar
creciendo de modo que si por ejemplo, en este momento una consulta
aceptable no dura mas de 15 segundos y con el tiempo por la carga de
datos en el mismo, dicha consulta excede ese límite, vas a estar
tumbando consultas que quizá por uno o dos segundos más se pudieron
ejecutar y que en su forma actual son lo mas correcto y optimizado.
Yo me iría más a la parte de la capacidad de quienes desarrollan la
aplicación o aplicaciones que van a trabajar sobre esa base de datos.
Recuerden ese viejo adagio de que la pre-optimización es el origen de
muchos males en desarrollo :D (o algo así :D).
Saludos a todos.
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
