On 3 March 2012 20:22, Jeff Janes <jeff.janes@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