Re: Slow PITR restore

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Slow PITR restore
Дата
Msg-id 476043D4.7090501@commandprompt.com
обсуждение исходный текст
Ответ на Re: Slow PITR restore  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-general
Gregory Stark wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>
>> On Wed, 12 Dec 2007 18:02:39 +0000
>> Gregory Stark <stark@enterprisedb.com> wrote:
>>
>>> I'm not sure what you guys' expectations are, but if you're restoring
>>> 5 minutes worth of database traffic in 8 seconds I wouldn't be
>>> complaining.
>> I would be. This is a database that is doing nothing but restoring.
>> Zero concurrency. This thing should be flying.
>
> Well you say that like concurrency is a bad thing. The lack of concurrency is
> the big handicap recovery has. It has to wait while it loads one buffer so it
> can twiddle some bits before it reads the next buffer and twiddles bits there.
> During normal operation those two buffers were twiddled by two different
> transactions in two different processes. Even if they weren't on two different
> processes they could have been context switched onto the same processor while
> the i/o was in progress.

Please see my point about saturation in another post.

Joshua D. Drake




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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Slow PITR restore
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: Altering field passed as parameter to plpgsql trigger