| 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: | Whole Thread | Raw Message | 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(*) |