On 30-Aug-05, at 12:29, Tom Lane wrote:

=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> 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.
Per NetApp, the disk utilization percentage they report does include seek time, not just read/write operations. NetApp has been involved in trying to figure out what is going on and their claim is that the NetApp filer is not IO bound.

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.
Yes, most of those queries are doing an indexscan. It's a fresh restore of our production database that we have vacuumed/analyzed.

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).
Will try to cluster the tables and see if it changes anything. Still doesn't explain what is going on with those seeks.



                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to