Re: Slow PITR restore - Mailing list pgsql-general

From Gregory Stark
Subject Re: Slow PITR restore
Date
Msg-id 87mysf3bwn.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Slow PITR restore  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Slow PITR restore
List pgsql-general
"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.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: what is the date format in binary query results
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Slow PITR restore