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
