Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 33EF02E004B for ; Mon, 19 May 2008 12:47:47 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 76620-01 for ; Mon, 19 May 2008 12:47:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by developer.postgresql.org (Postfix) with ESMTP id 5104A2E0048 for ; Mon, 19 May 2008 12:47:41 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m4JFlckj028926; Mon, 19 May 2008 11:47:38 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m4JFlc9L028923; Mon, 19 May 2008 11:47:38 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Mon, 19 May 2008 11:47:38 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Matthew Wakeling cc: pgsql-performance@postgresql.org Subject: Re: I/O on select count(*) In-Reply-To: Message-ID: References: <920841.71690.qm@web44808.mail.sp1.yahoo.com> <482B1D5F.EE98.0025.0@wicourts.gov> <20080515020553.GN9838@alvh.no-ip.org> <20080515155232.GC8221@alvh.no-ip.org> <20080516201528.GJ13061@alvh.no-ip.org> <18382.1210992302@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/268 X-Sequence-Number: 30236 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