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(*)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: I/O on select count(*)  (PFC <lists@peufeu.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: I/O on select count(*)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: I/O on select count(*)