Re: I/O on select count(*)
От | Greg Smith |
---|---|
Тема | Re: I/O on select count(*) |
Дата | |
Msg-id | Pine.GSO.4.64.0805191137480.25115@westnet.com обсуждение исходный текст |
Ответ на | Re: I/O on select count(*) (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: I/O on select count(*)
Re: I/O on select count(*) |
Список | 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@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления: