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: | Raw Message | Whole Thread | 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 ...)" |