On Fri, Nov 11, 2011 at 2:09 PM, Steve Singer <[email protected]> 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. _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
