Re: [PERFORMANCE] expanding to SAN: which portion best to move
От | Craig Ringer |
---|---|
Тема | Re: [PERFORMANCE] expanding to SAN: which portion best to move |
Дата | |
Msg-id | 4DD2441D.8040500@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: [PERFORMANCE] expanding to SAN: which portion best to move (Robert Klemme <shortcutter@googlemail.com>) |
Ответы |
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 |
Список | 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 по дате отправления: