Re: Slow PITR restore

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Slow PITR restore
Date: 2007-12-12 11:30:25
Message-ID: 1197459025.4255.1537.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, 2007-12-12 at 08:55 +0000, Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
> > Wow, o.k. well it is something we (the community) really should look at for
> > 8.4. I am surprised that it is slower than just walking through the xlogs on
> > recovery. I am sure there is a reason just surprised.

It's the same speed because it is the same recovery code.

> Well in the worst case it has to do nearly as much work as the original
> database did. And it only gets to use 1 cpu so it can only have one i/o
> request pending.

That need only be slow in certain circumstances.

> bgwriter is started already when doing recovery, right? Perhaps things could
> be helped by telling bgwriter to behave differently during recovery.

It would certainly help if bgwriter came up earlier. I've been looking
at that just recently. The main issue is how to structure the code to
tell bgwriter when it can start processing in recovery mode and then
move into normal mode.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2007-12-12 11:38:08 Re: Hijack!
Previous Message Daniel Verite 2007-12-12 11:23:18 Re: Using hashtext and unique constraints together

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas ADI SD 2007-12-12 11:58:11 Re: WORM and Read Only Tables (v0.1)
Previous Message Zeugswetter Andreas ADI SD 2007-12-12 11:14:43 Re: WORM and Read Only Tables (v0.1)