| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORMANCE] expanding to SAN: which portion best to move |
| Date: | 2011-05-17 09:47:09 |
| Message-ID: | 4DD2441D.8040500@postnewspapers.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cédric Villemain | 2011-05-17 10:06:31 | Re: Memcached for Database server |
| Previous Message | Gerhard Hintermayer | 2011-05-17 09:30:10 | Re: ordering of join using ON expression = any (array) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cédric Villemain | 2011-05-17 10:13:21 | Re: [PERFORMANCE] expanding to SAN: which portion best to move |
| Previous Message | Clemens Eisserer | 2011-05-17 07:38:55 | Re: hash semi join caused by "IN (select ...)" |