Re: I/O on select count(*)

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

In response to

Responses

Browse pgsql-performance by date

  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(*)