From: | "Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)com> |
---|---|
To: | "Bruce Momjian" <bruce(at)momjian(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Documenting pglesslog |
Date: | 2009-01-14 04:03:18 |
Message-ID: | a778a7260901132003r7b357360n174c736e88101a64@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
--
------
Koichi Suzuki
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2009-01-14 04:09:34 | Re: solaris libpq threaded build fails |
Previous Message | Stephen Frost | 2009-01-14 03:53:43 | Re: A single escape required for log_filename |