Re: [PERFORMANCE] expanding to SAN: which portion best to move - Mailing list pgsql-performance

From Craig Ringer
Subject Re: [PERFORMANCE] expanding to SAN: which portion best to move
Date
Msg-id 4DD2441D.8040500@postnewspapers.com.au
Whole thread Raw
In response to Re: [PERFORMANCE] expanding to SAN: which portion best to move  (Robert Klemme <shortcutter@googlemail.com>)
Responses Re: [PERFORMANCE] expanding to SAN: which portion best to move
Re: [PERFORMANCE] expanding to SAN: which portion best to move
Re: [PERFORMANCE] expanding to SAN: which portion best to move
List pgsql-performance
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.

--
Craig Ringer

pgsql-performance by date:

Previous
From: Clemens Eisserer
Date:
Subject: Re: hash semi join caused by "IN (select ...)"
Next
From: Cédric Villemain
Date:
Subject: Re: [PERFORMANCE] expanding to SAN: which portion best to move