2011/5/17 Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>: > 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. Prefetching is used in bitmapheapscan. The GUC effeective_io_concurrency allow you increase the prefetch window. > > -- > Craig Ringer > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ ; PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
