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  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
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  (Greg Smith <greg@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Clemens Eisserer
Дата:
Сообщение: Re: hash semi join caused by "IN (select ...)"
Следующее
От: Cédric Villemain
Дата:
Сообщение: Re: [PERFORMANCE] expanding to SAN: which portion best to move