From: | Silvio Quadri <silvioq(at)gmail(dot)com> |
---|---|
To: | OgiSer Tamade <tamade(dot)ogiser(at)gmail(dot)com> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: [pgsql-es-ayuda] Re: Saturación PostgreSQL |
Date: | 2010-07-15 12:42:24 |
Message-ID: | AANLkTimUn2myJKCy2D6st1-bnapXyg1jzxMIJB0NZju9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El día 15 de julio de 2010 04:16, OgiSer Tamade
<tamade(dot)ogiser(at)gmail(dot)com> escribió:
> Voy a cambiar la consulta para que se realice secuencial no obstante
> creo que el problema puede venir por assignedto ya que cuando ocurre
> casi todos los registros tienen ese campo a null.
Entonces te conviene trabajar sobre la fecha esa callback no sé cuanto ...
una posibilidad es cambiar los nulos por una fecha muy baja .... ahí
quizás encuentre el primer registro inmediatamente.
>
> Lo extraño es que el explain cuando el sistema esta parado es bajísimo
> pero con 90 usuarios tengo tiempos en torno a 10 segundos.
¿Lockeos?
>
>>
>> Yo creo que lo que habría que hacer aquí es librarse del subselect en la
>> lista de resultados (ese que trae el MAX() de no sé qué), y convertirlo
>> en un join o en una subconsulta que sea más optimizable.
Me da la impresión, por el explain que eso está bien. De todas formas,
lo que debería hacer es quitar el subselect y ver si cambia el plan.
--
Silvio Quadri
From | Date | Subject | |
---|---|---|---|
Next Message | OgiSer Tamade | 2010-07-15 12:46:44 | Re: [pgsql-es-ayuda] Re: Saturación PostgreSQL |
Previous Message | OgiSer Tamade | 2010-07-15 07:16:22 | Re: Saturación PostgreSQL |