Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 31ADE64FD0B
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 15 Dec 2008 08:02:50 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 29994-06
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 15 Dec 2008 08:02:43 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158])
	by mail.postgresql.org (Postfix) with ESMTP id 7E50F64FC1E
	for <pgsql-performance@postgresql.org>;
	Mon, 15 Dec 2008 08:02:42 -0400 (AST)
Received: by fg-out-1718.google.com with SMTP id 16so1153373fgg.23
	for <pgsql-performance@postgresql.org>;
	Mon, 15 Dec 2008 04:02:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=wU42/3uhBgdevfx/q1h0QwrlKeV+Kdq0kyLWA8nD7zk=;
	b=HTTinsMaACCAgBsIJ7+GSOMvpk57aqohjg0ukw6c8pJHQ2DNrGznIyTWbTsF7VXmY9
	xP7WnWosA1bHfuo/LOCvfmKwLq70ttCcmFnZy3OnWvyl2wcpVtRPFwKBmr35ttMj/lXy
	tsXo1Y5QWkmcvvyZF/NtRMxYebRGN8Z7nQfIw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:references;
	b=FXioBwyEk5mAnL7vbht/vNlnXffXQYOjKdYc2Q3cInnVRcDY85VNeMooxAVpYhFRzT
	/9+R90ZIy80o2Wd1X/hVrNBrQYXX7HhZ7Am9njf/A+JfoNOPwhrUeDIGHihYW7Iy88mV
	RkMJhOKZUsjxSAutF3BN+lyhzNp0jCQrHJzQw=
Received: by 10.86.86.12 with SMTP id j12mr3792993fgb.33.1229342559602;
	Mon, 15 Dec 2008 04:02:39 -0800 (PST)
Received: by 10.86.1.8 with HTTP; Mon, 15 Dec 2008 04:02:39 -0800 (PST)
Message-ID: <1d709ecc0812150402v62375a88y121d5515d7210cd2@mail.gmail.com>
Date: Mon, 15 Dec 2008 15:02:39 +0300
From: "Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>
To: "Adrian Moisey" <adrian@careerjunction.co.za>
Subject: Re: filesystems benchmark
Cc: pgsql-performance@postgresql.org
In-Reply-To: <4945FD58.8030604@careerjunction.co.za>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_99638_1725155.1229342559602"
References: <4945FD58.8030604@careerjunction.co.za>
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: 200812/155
X-Sequence-Number: 32191

------=_Part_99638_1725155.1229342559602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
> I'm trying to compare different filesystems for postgres using pgbench.
>  The problem I've seen is that my IO wait is very very low.  Is there a way
> I can get pgbench to do more to push that up a little?

Why do you expect to see high IO wait?

Does your database fit in system memory? If you do not modify the data and
it is not large enough, it is unlikely you will hit IO wait.

Do you have write cache enabled for the file system/device? Even if you have
some DML statements, it would not be that easy to saturate write cache
enabled storage (especially, when it fits in memory).


Regards,
Vladimir Sitnikov

------=_Part_99638_1725155.1229342559602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m trying to compare different filesystems for postgres using pgbench. &nbsp;The problem I&#39;ve seen is that my IO wait is very very low. &nbsp;Is there a way I can get pgbench to do more to push that up a little?</blockquote>
<div>Why do you expect to see high IO wait? <br><br>Does your database fit in system memory? If you do not modify the data and it is not large enough, it is unlikely you will hit IO wait.<br><br>
Do you have write cache enabled for the file system/device? Even if you have some DML statements, it would not be that easy to saturate write cache enabled storage (especially, when it fits in memory).<br><br><br></div></div>
Regards,<br>Vladimir Sitnikov<br>

------=_Part_99638_1725155.1229342559602--