Re: [GENERAL] Slow PITR restore - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: [GENERAL] Slow PITR restore
Date
Msg-id 87zlwf0vxw.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Re: [GENERAL] Slow PITR restore  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> On Thu, 2007-12-13 at 06:27 +0000, Gregory Stark wrote:
>> Heikki proposed a while back to use posix_fadvise() when processing logs to
>> read-ahead blocks which the recover will need before actually attempting to
>> recover them. On a raid array that would bring the 3MB/s above up to the
>> maximum number of random accesses the raid array can handle (ie, definition
>> (2) above).
>
> It's a good idea, but it will require more complex code. I prefer the
> simpler solution of using more processes to solve the I/O problem.

Huh, I forgot about that idea. Ironically that was what I suggested when
Heikki described the problem.

I think it's more complex than using posix_fadvise. But it's also more
ambitious. It would allow us to use not only the full random access i/o
bandwidth but also allow us to use more cpu. In cases where the database fits
entirely in ram and we're recovering many many operations modifying the same
blocks over and over that might help a lot.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [GENERAL] Slow PITR restore
Next
From: Simon Riggs
Date:
Subject: Re: [GENERAL] Slow PITR restore