Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id C06A52E00C0
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed, 14 May 2008 17:11:34 -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 17165-01-4
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed, 14 May 2008 17:11:27 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from n75.bullet.mail.sp1.yahoo.com (n75.bullet.mail.sp1.yahoo.com
	[98.136.44.51])
	by developer.postgresql.org (Postfix) with SMTP id 59ED92E0065
	for <pgsql-performance@postgresql.org>;
	Wed, 14 May 2008 17:09:52 -0300 (ADT)
Received: from [216.252.122.217] by n75.bullet.mail.sp1.yahoo.com with NNFMP;
	14 May 2008 20:09:49 -0000
Received: from [69.147.84.100] by t2.bullet.sp1.yahoo.com with NNFMP;
	14 May 2008 20:09:49 -0000
Received: from [127.0.0.1] by omp201.mail.sp1.yahoo.com with NNFMP;
	14 May 2008 20:09:49 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 29948.45377.bm@omp201.mail.sp1.yahoo.com
Received: (qmail 71723 invoked by uid 60001); 14 May 2008 20:09:48 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=59GkvRVltbpDjdLIUpvC10dBcTCEWa+6h2gd8VVAYpwkpjF9cup5bCAZUVoi+Z1jvY6MkbxmrY8+Tft+OCqgml9bc467jSnpvrodAIJUKMwbXQbC7rj+C7U1ZmjhW8iXn46URxFiRiYmbQTLal/l9slFacxakDN/Y5+9cJNCZLE=;
Received: from [66.39.195.151] by web44808.mail.sp1.yahoo.com via HTTP;
	Wed, 14 May 2008 13:09:48 PDT
X-Mailer: YahooMailRC/975.38 YahooMailWebService/0.7.199
Date: Wed, 14 May 2008 13:09:48 -0700 (PDT)
From: Doug Eck <deck1@yahoo.com>
Reply-To: Doug Eck <deck1@yahoo.com>
Subject: I/O on select count(*)
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1708251028-1210795788=:71690"
Message-ID: <920841.71690.qm@web44808.mail.sp1.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200805/183
X-Sequence-Number: 30151

--0-1708251028-1210795788=:71690
Content-Type: text/plain; charset=us-ascii

I have a large table (~ 2B rows) that contains an indexed timestamp column.  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.  We have determined that files in our data and log partitions are being hit, but the file system itself is not growing during this time (it appears to be writing over the same chunk of space over and over again).  Memory on the box is not being swapped while all of this is happening.  I would have guessed that a "select count(*)" would not require a bunch of writes, and I can't begin to figure out why the number of blocks written are so much higher than the blocks read.  If I modify the where clause to only count the rows for a given minute or two, I see the reads but I never see the unusual write behavior.

Any thoughts into what could be going on?  Thanks in advance for your help.

Doug



      
--0-1708251028-1210795788=:71690
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>I have a large table (~ 2B rows) that contains an indexed timestamp column.&nbsp; 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'".&nbsp; 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.&nbsp; My question concerns some unusual I/O activity on the box (SUSE)&nbsp; when I run the query.<br><br>For the first couple of minutes I see reads only.&nbsp; After that vmstat shows mixed reads and writes in a ratio of about 1 block read to 5 blocks written.&nbsp; We have determined that files in our data and log partitions are being hit, but the file system itself is
 not growing during this time (it appears to be writing over the same chunk of space over and over again).&nbsp; Memory on the box is not being swapped while all of this is happening.&nbsp; I would have guessed that a "select count(*)" would not require a bunch of writes, and I can't begin to figure out why the number of blocks written are so much higher than the blocks read.&nbsp; If I modify the where clause to only count the rows for a given minute or two, I see the reads but I never see the unusual write behavior.<br><br>Any thoughts into what could be going on?&nbsp; Thanks in advance for your help.<br><br>Doug<br></div></div><br>

      </body></html>
--0-1708251028-1210795788=:71690--