On Fri, Nov 11, 2011 at 2:09 PM, Steve Singer <ssinger at ca.afilias.info> wrote:
>>  From my postgresql.log:
>> 2011-11-11 11:03:15.237 PST db1.lax.jib(55096):LOG:  duration: 133.011 ms  statement: fetch 500 from LOG;
>> 2011-11-11 11:03:17.241 PST db1.lax.jib(55096):LOG:  duration: 134.842 ms  statement: fetch 500 from LOG;
>> 2011-11-11 11:03:19.239 PST db1.lax.jib(55096):LOG:  duration: 133.919 ms  statement: fetch 500 from LOG;
>> 2011-11-11 11:03:21.240 PST db1.lax.jib(55096):LOG:  duration: 133.194 ms  statement: fetch 500 from LOG;
>> 2011-11-11 11:03:23.241 PST db1.lax.jib(55096):LOG:  duration: 134.288 ms  statement: fetch 500 from LOG;
>> 2011-11-11 11:03:25.241 PST db1.lax.jib(55096):LOG:  duration: 133.226 ms  statement: fetch 500 from LOG;
>
> The fetch is taking a long time because sl_log_1 is big.  (The reason it
> takes so long is actually a bug that was fixed in 2.1)  sl_log_1 being
> that big probably means that log switching isn't happening.

Let me observe that 133ms is not a terribly long time.  It's possible
that everything's working just AOK.  If it was 133 seconds, that would
be one thing.  But 133ms isn't "obviously broken."

Perhaps the query would be somewhat faster if we had the query change
from 2.1 in place here, but I still don't imagine it would run without
*any* duration, not even if we were running this on a Cray :-).
-- 
Have you heard about the new Cray super computer? It's so fast, it
executes an infinite loop in 6 seconds.