"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Manoel Henrique" <[EMAIL PROTECTED]> writes: >>> Yes, I'm relying on the assumption that backwards scan has the same cost as >>> forward scan, why shouldn't it? > >> Because hard drives only spin one direction > > Good joke, but to be serious: we expect that forward scans will result > in the kernel doing read-ahead, which will allow overlapping of > CPU work to process one page with the I/O to bring in the next page.
Well it wasn't a joke but you're right that it's not the whole picture. But then neither is considering interleaving of I/O with CPU work. Hard drives spin in a particular direction which means if you stream I/O requests to them in that direction you can stream data off the hard drive as fast as it passes under the read head. That's going to be 50-60MB/s for a single modern 7200rpm drive. On the other hand if you send an I/O request for the previous block then you have to wait a whole rotation before it passes under the head. On a 7200rpm drive that's over 8ms which is a *lot* of CPU work to interleave. The most bandwidth you'll be able to get is under 1MB/s. However there's another reason fadvise helps -- the kernel or the drive gets a chance to reorder the I/O. If we read-ahead a whole track's worth of I/O backwards then during the first 8ms latency the kernel has a chance to notice that it should reorder the queued up requests and do them the right way around. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
