Re: Slow PITR restore

Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
>> On Wed, 12 Dec 2007 18:02:39 +0000
>> Gregory Stark <stark(at)enterprisedb(dot)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