Re: Slow PITR restore

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Slow PITR restore
Date: 2007-12-12 17:19:55
Message-ID: 4760183B.7060204@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> On Tue, 2007-12-11 at 22:21 -0500, Tom Lane wrote:
>>> Yeah, restoring is known to be less than speedy, because essentially
>>> zero optimization work has been done on it.
>
>> If there was a patch to improve this, would it be applied to 8.3?
>
> Good grief, no. We have not even done the research to find out where
> the bottleneck(s) is/are. We're not holding up 8.3 while we go back
> into development mode, especially not when this problem has existed
> for seven or eight years (even if JD failed to notice before) and
> there are already some improvements for it in 8.3.

I would also note that this "problem" is only going to be noticeable on
the highest velocity of databases. This is certainly a 10% of the users
issue. It would be great to get it fixed but there are ways around it
(namely making sure you are running pg_standby and pushing logs at
smaller intervals).

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Simon Riggs 2007-12-12 17:36:45 Re: Slow PITR restore
Previous Message Gregory Stark 2007-12-12 17:19:43 Re: WHERE (columnX IN (x,y,z)) ORDER BY columnY conflict

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-12-12 17:22:56 test
Previous Message Tom Lane 2007-12-12 17:13:58 Re: Slow PITR restore