From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nathan Boley <npboley(at)gmail(dot)com> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Ogden <lists(at)darkstatic(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance |
Date: | 2011-04-14 00:03:09 |
Message-ID: | 1809.1302739389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Nathan Boley <npboley(at)gmail(dot)com> writes:
> FWIW, awhile ago I wrote a simple script to measure this and found
> that the *actual* random_page / seq_page cost ratio was much higher
> than 4/1.
That 4:1 ratio is based on some rather extensive experimentation that
I did back in 2000. In the interim, disk transfer rates have improved
quite a lot more than disk seek times have, and the CPU cost to process
a page's worth of data has also improved compared to the seek time.
So yeah, you'd likely get a higher number if you redid those experiments
on modern hardware (at least assuming it was rotating media and not SSD).
On the other hand, the effects of caching push the numbers in the other
direction, and modern machines also have a lot more RAM to cache in than
was typical ten years ago. I'm not sure how much point there is in
trying to improve the default number in the abstract --- we'd really
need to have a more robust model of cache effects before I'd trust any
automatic tuning procedure to set the value for me.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2011-04-14 00:37:05 | Re: Performance |
Previous Message | Tomas Vondra | 2011-04-13 23:26:29 | Re: Performance |