Re: How is random_page_cost=4 ok?

On Fri, 10 Oct 2008, Tom Lane wrote:

> In particular, if the OS lays out successive file pages in a way that
> provides zero latency between logically adjacent blocks, I'd bet a good
> bit that a Postgres seqscan would miss the read timing every time, and
> degrade to handling about one block per disk rotation.

The drives themselves, and possibly the OS and disk controller, are all 
running read-ahead algorithms to accelerate this case.  In fact, this 
*exact* case for the Linux read-ahead stuff that just went mainline 
recently: http://kerneltrap.org/node/6642

I was reading something the other day about how drives with bigger caches 
are starting to have firmware tuned to just start reading from wherever 
the head happens to be end up at once the seek has found the right area, 
even if it's not what you asked for, in hopes that you'll want those 
nearby blocks soon, too.  If the drive has 32MB of cache in it and you're 
seeking around, you've got a pretty big working area relative to how fast 
you can fill that with requested data.

And then there's a patch that helps accelerate this process I should get 
back to benchmarking again...

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD