Adding to this: Ayush recently wrote a C program that emulates PG IO to do this analysis, and we came out with (predictably) a ratio of sequential/random of 20-50 (for a single user). This is predictable because the random component is fixed at the access time of a single hard drive no matter how many disks are in an array, while the sequential scales nearly linearly with the number of drives in the array.
So, you can estimate random using 8-12ms per random access, and sequential as 1/(number of disks X 60-130MB/s). Ayush, can you forward your C program? - Luke Msg is shrt cuz m on ma treo -----Original Message----- From: Gregory Stark [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 12:37 PM Eastern Standard Time To: Tom Lane Cc: Umar Farooq Minhas; email@example.com Subject: Re: [HACKERS] Estimating seq_page_fetch and random_page_fetch "Tom Lane" <[EMAIL PROTECTED]> writes: > "Umar Farooq Minhas" <[EMAIL PROTECTED]> writes: >> How can we accrately estimate the "seq_page_fetch" and = >> "random_page_fetch" costs from outside the postgres using for example a = >> C routine. > > Use a test case larger than memory. Repeat many times to average out > noise. IIRC, when I did the experiments that led to the current > random_page_cost of 4.0, it took about a week before I had numbers I > trusted. When I was running tests I did it on a filesystem where nothing else was running. Between tests I unmounted and remounted it. As I understand it Linux associates the cache with the filesystem and not the block device and discards all pages from cache when the filesystem is unmounted. That doesn't contradict anything Tom said, it might be useful as an additional tool though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq