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.
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?)
No.
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.
Thanks,
Rémy
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
