Re: [GENERAL] Slow PITR restore

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: [GENERAL] Slow PITR restore
Дата
Msg-id 87zlwf0vxw.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Re: [GENERAL] Slow PITR restore  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> On Thu, 2007-12-13 at 06:27 +0000, Gregory Stark wrote:
>> Heikki proposed a while back to use posix_fadvise() when processing logs to
>> read-ahead blocks which the recover will need before actually attempting to
>> recover them. On a raid array that would bring the 3MB/s above up to the
>> maximum number of random accesses the raid array can handle (ie, definition
>> (2) above).
>
> It's a good idea, but it will require more complex code. I prefer the
> simpler solution of using more processes to solve the I/O problem.

Huh, I forgot about that idea. Ironically that was what I suggested when
Heikki described the problem.

I think it's more complex than using posix_fadvise. But it's also more
ambitious. It would allow us to use not only the full random access i/o
bandwidth but also allow us to use more cpu. In cases where the database fits
entirely in ram and we're recovering many many operations modifying the same
blocks over and over that might help a lot.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [GENERAL] Slow PITR restore
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [GENERAL] Slow PITR restore