Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 7DE502E0031 for ; Wed, 14 May 2008 19:11:32 -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 78660-05 for ; Wed, 14 May 2008 19:11:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by developer.postgresql.org (Postfix) with ESMTP id 2DBBC2E002D for ; Wed, 14 May 2008 19:11:29 -0300 (ADT) Received: from Courts-MTA by gwmta.wicourts.gov with Novell_GroupWise; Wed, 14 May 2008 17:11:27 -0500 Message-Id: <482B1D5F.EE98.0025.0@wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Wed, 14 May 2008 17:11:21 -0500 From: "Kevin Grittner" To: ,"Doug Eck" Subject: Re: I/O on select count(*) References: <920841.71690.qm@web44808.mail.sp1.yahoo.com> In-Reply-To: <920841.71690.qm@web44808.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/186 X-Sequence-Number: 30154 >>> Doug Eck wrote: > I am attempting to run a query to determine the number of rows for a given > day using something like "select count(*) from tbl1 where ts between > '2008-05-12 00:00:00.000' and '2008-05-12 23:59:59.999'". Explain tells me > that the query will be done using an index scan (as I would expect), and I > realize that it is going to take a while. My question concerns some unusual > I/O activity on the box (SUSE) when I run the query. > > For the first couple of minutes I see reads only. After that vmstat shows > mixed reads and writes in a ratio of about 1 block read to 5 blocks written. > Any thoughts into what could be going on? Thanks in advance for your help. Odd as it may seem, a SELECT can cause a page to be rewritten. If this is the first time that the rows are being read since they were inserted (or since the database was loaded, including from backup), it may be rewriting the rows to set hint bits, which can make subsequent access faster. The best solution may be to vacuum more often. http://archives.postgresql.org/pgsql-performance/2007-12/msg00206.php -Kevin