On Tue, May 17, 2011 at 11:47 AM, Craig Ringer <cr...@postnewspapers.com.au> wrote: > On 05/17/2011 03:00 PM, Robert Klemme wrote: > >> The main point is that you do not benefit from the larger IO bandwidth >> if access patterns do not permit parallel access to both disks (e.g. >> because you first need to read index blocks in order to know the table >> blocks to read). > > This makes me wonder if Pg attempts to pre-fetch blocks of interest for > areas where I/O needs can be known in advance, while there's still other > works or other I/O to do. For example, pre-fetching for the next iteration > of a nested loop while still executing the prior one. Is it even possible? > > I'm guessing not, because (AFAIK) Pg uses only synchronous blocking I/O, and > with that there isn't really a way to pre-fetch w/o threads or helper > processes. Linux (at least) supports buffered async I/O, so it'd be possible > to submit such prefetch requests ... on modern Linux kernels. Portably doing > so, though - not so much.
There is a much more serious obstacle than the mere technical (if that was one at all): prefetching is only reasonable if you can predict which data you need with high probability (say >= 80%). If you can't you'll have much more IO than without prefetching and overall performance likely suffers. Naturally that probability depends on the data at hand and the access pattern. As Cédric wrote, there seems to be at least one case where it's done. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
