From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: I/O on select count(*) |
Date: | 2008-05-19 15:47:38 |
Message-ID: | Pine.GSO.4.64.0805191137480.25115@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 19 May 2008, Matthew Wakeling wrote:
> Does it really take that long to zero out 8kB of RAM? I thought CPUs were
> really quick at doing that!
You don't get the whole CPU--you get time slices of one. Some of the
cases complaints have come in about have over a thousand connections all
fighting for CPU time, and making every one of them block for one guy who
needs to fiddle with memory for a while can be a problem. If you're
unlucky you won't even be on the same CPU you started on each time you get
a little check of time, and you'll run at the speed of RAM rather than
that of the CPU--again, fighting for RAM access with every other process
on the server.
The real question in my mind is why this turns into a bottleneck before
the similar task of cleaning the 16MB XLOG segment does. I expected that
one would need to be cracked before the CLOG switch time could possibly be
an issue, but reports from the field seem to suggest otherwise.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-19 15:53:49 | Re: I/O on select count(*) |
Previous Message | Tom Lane | 2008-05-19 15:37:58 | Re: I/O on select count(*) |