Re: pgsql: Add URLs for : * Speed WAL recovery by allowing more than one - Mailing list pgsql-committers

From Gregory Stark
Subject Re: pgsql: Add URLs for : * Speed WAL recovery by allowing more than one
Date
Msg-id 874pb3lrun.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: pgsql: Add URLs for : * Speed WAL recovery by allowing more than one  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pgsql: Add URLs for : * Speed WAL recovery by allowing more than one  (Bruce Momjian <bruce@momjian.us>)
List pgsql-committers
"Bruce Momjian" <bruce@momjian.us> writes:

>> > > On Tue, 2008-03-18 at 03:59 +0000, Bruce Momjian wrote:
>> > > > * Speed WAL recovery by allowing more than one page to be prefetched
>> > > >
>> > > >   This involves having a separate process that can be told which pages
>> > > >   the recovery process will need in the near future.
>
> Are you reading the same thread I am?  See:
>
>     http://archives.postgresql.org/pgsql-hackers/2008-02/msg01301.php

I don't think there's any consensus for the approach you describe above. If
anything it seemed the least objectionable form was something involving
posix_fadvise or libaio.

Tom did wave us off from Simon's approach on the basis of it being hard to
test and Heikki seemed to be agreeing on the basis that it would be better to
reuse infrastructure useful in other cases as well. So I guess that's some
kind of consensus... of two.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

pgsql-committers by date:

Previous
From: momjian@postgresql.org (Bruce Momjian)
Date:
Subject: pgsql: Add to TODO: > > * Consider not storing a NULL bitmap on disk
Next
From: Bruce Momjian
Date:
Subject: Re: pgsql: Add URLs for : * Speed WAL recovery by allowing more than one