On 3 March 2012 20:22, Jeff Janes <jeff.ja...@gmail.com> wrote: > Add it all up, and instead of pre-reading 32 consecutive 8K blocks, it > pre-reads only about 1 or 2 consecutive ones on the final merge. Now > some of those could be salvaged by the kernel keeping track of > multiple interleaved read ahead opportunities, but in my hands vmstat > shows a lot of IO wait and shows reads that seem to be closer to > random IO than large read-ahead. If it used truly efficient read > ahead, CPU would probably be limiting.
Can you suggest a benchmark that will usefully exercise this patch? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
