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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
