From: | Douglas McNaught <doug(at)mcnaught(dot)org> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | PFC <lists(at)peufeu(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-18 02:55:55 |
Message-ID: | 87zmgbuq84.fsf@suzuka.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> PFC <lists(at)peufeu(dot)com> writes:
>
>> - Will only be of use if the command is taking a long, long time.
>> So, it need not be realtime ; no problem if the data comes with a
>> little delay, or not at all if the command executes quickly.
>
> I would dispute this point. Picture a system running a very short very very
> often. It may still be the main problem, may even be taking 90+% of the cpu
> time. If you got an accurate snapshot of all the currently executing queries
> you'll see it popping up suspiciously often.
Yeah, but if you turn on query logging in that case you'll see the
bajillions of short queries, so you don't need the accurate snapshot
to diagnose that.
-Doug
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-06-18 07:42:24 | Re: Rethinking stats communication mechanisms |
Previous Message | Greg Stark | 2006-06-18 02:46:04 | Re: Rethinking stats communication mechanisms |