Re: How is random_page_cost=4 ok?

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at>
Cc: Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How is random_page_cost=4 ok?
Date: 2008-10-10 13:39:05
Message-ID: 87zllc1see.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at> writes:

> I think your numbers are a bit off:
>
> For "Consumer drives" (7.200 RPM SATA 3.5"), seek times are much worse, in the
> area of 8-9ms (see [1]), but sustained sequential read numbers are noticeable
> higher, around 80-90MB/sec.

I took the seek latency from the data sheet for a Barracuda 7200.9 which is
several generations old but still a current model. Just rotational latency
would have a worst case of 8.3ms and half that is precisely the 4.16 they
quote so I suspect that's where the number comes from. Not especially helpful
perhaps.

They don't quote sustained bandwidth for consumer drives but 50-60MB/s are the
numbers I remembered -- admittedly from more than a couple years ago. I didn't
realize 7200 RPM drives had reached such speeds yet.

But with your numbers things look even weirder. With a 90MB/s sequential speed
(91us) and 9ms seek latency that would be a random_page_cost of nearly 100!

> For "Server Drives" 3-4ms are more realistic ([2], [3]) for average seeks and
> the 110-170MB/sec are highly exaggerated.

In that case both of those numbers come straight from Seagate's data sheet for
their top-of-the-line data centre drives:

http://www.seagate.com/docs/pdf/datasheet/disc/ds_cheetah_15k_6.pdf

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-10 13:41:39 CLUSTER, REINDEX, VACUUM in "read only" transaction?
Previous Message Matthew Wakeling 2008-10-10 13:17:03 Re: CREATE DATABASE vs delayed table unlink