To: =?ISO-8859-1?Q?R=E9my_Beaumont?= <remyb@medrium.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: High load and iowait but no disk access 
In-reply-to: <2fa5224f3e5af53598e33d115a2af980@medrium.com> 
References: <bcd92b00545ffeef542f68666144099d@medrium.com>
	<22417.1125418551@sss.pgh.pa.us>
	<2fa5224f3e5af53598e33d115a2af980@medrium.com>
Comments: In-reply-to =?ISO-8859-1?Q?R=E9my_Beaumont?= <remyb@medrium.com>
	message dated "Tue, 30 Aug 2005 12:19:30 -0400"
Date: Tue, 30 Aug 2005 12:29:02 -0400
Message-ID: <22550.1125419342@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

=?ISO-8859-1?Q?R=E9my_Beaumont?= <remyb@medrium.com> writes:
> On 30-Aug-05, at 12:15, Tom Lane wrote:
>> I know zip about NetApps, but doesn't the 8th column indicate pretty
>> steady disk reads?

> Yes, but they are very low.

Sure, but that's more or less what you'd expect if the thing is randomly
seeking all over the disk :-(.  Just because it's a NetApp doesn't mean
it's got zero seek time.

You did not say what sort of query this is, but I gather that it's doing
an indexscan on a table that is not at all in index order.  Possible
solutions involve reverting to a seqscan (have you forced the planner to
choose an indexscan here, either directly or by lowering random_page_cost?)
or CLUSTERing the table by the index (which would need to be repeated
periodically, so it's not a great answer).

			regards, tom lane