Pg_readahead is a tool to prefetch data pages before redoing, based on the contents of archive/active WAL segment. For 8.3 and 8.4 without sync.rep, this works together with restore_command. Pg_readahead analyze WAL segment, schedule and issue posix_fadvise() to prefetch data pages quickly before redoing.
Discussions and materials will be found at http://archives.postgresql.org/pgsql-hackers/2008-10/msg01372.php So far, external command implemantation speeds up PITR up to six times! Therefore, overall recovery time can be a little longer than that with FPW. 2009/1/14 Bruce Momjian <br...@momjian.us>: > Koichi Suzuki wrote: >> Hi, >> >> I have no intention to make pglesslog to conflict to PostgreSQL >> license. Any advice is welcome to make pglesslog available without >> any license concern. > > I certainly have no concerns. > >> I've a question and ideas. >> >> Bruce's modification directly points to my pgfoundry page. I'm not >> sure what it means. Does it mean that I have to maintain the page for >> a while? If pglesslog helps for future releases, can it be a part of >> PostgreSQL release, as contrib module so that all the documentation in >> pgfoundry (although very simple) is included in the release material? > > I think eventually we should put pglesslog into /contrib, and if we ever > do that, we would update your web page. I have not heard any mention of > it being moved into /contrib for 8.4 though. > > If you would like me to point to another URL, please let me know. > > I think there is definately demand for pglesslog because not only does > it truncate dead space from the WAL file, it also removes full page > write images, and is best done in archive_command, and hence externally > like your tool does. > >> As many hackers know, I've posted another code to speedup PITR after >> slipping FPW, which does work with 8.3 as external module >> (pg_readahead). I'm now working to work this with synchronous >> replication. Maybe it's a good idea to use pglesslog with >> pg_readahead. Although I'm not sure if pg_readahead integration >> with synchronous replication will be done within 8.4 development >> period, I'm quite ready to post pg_readahead for 8.4 sililar to that >> for 8.3, which also could be in contrib module. > > Sorry, I don't know enough about pg_readahead. > > -- > Bruce Momjian <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > -- ------ Koichi Suzuki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
