2011/5/17 Craig Ringer <craig@postnewspapers.com.au>:
> 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@postgresql.org)
> 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
