Re: Re: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

Thanks a lot for the comment/advice.   Yes, full page backup block
considerablly shortens the recovery time.   As we discussed about two
years ago, I have a solution accelerate the recovery even without full
page image.   I'd like to submit this solution to the community again.  When I evaluated this two years ago, recovery
speedwas as good as 
those with full page image, depending upon application and tuning, of
course.

This is a separate tool and can be used in various scenes.

Regards;
----------
Koichi Suzuki



2010/5/13 Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>:
>
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Bruce Momjian <bruce@momjian.us> writes:
>> > Yes, I would love to get this into /contrib for PG 9.1!
>>
>> How much are people really going to care about pg_lesslog now that
>> we've got streaming replication?  There might be some small use-case
>> still left, but it's hard to believe that it would be worth carrying
>> it in contrib.
>
> I hope pg_lesslog would work as a WAL filter of streaming replication.
> It might be hard-coded in WAL sender, or be an addon based on a new
> common filtering infrastructure of WAL streaming.
>
> Also, there is a long-standing issue in pg_lesslog; It slows down recovery
> because we need to read data pages before write in recovery. We're avoiding
> reading pages for full-page image in 8.3, but pg_lesslog will disable
> the optimization. Recovery routine in core also needs to be adjusted to use
> read-ahead, like posix_fadvise().
>
> There was another idea, full-page image logs separated with WAL logging.
> In theory, full-page images don't have to be written at commit, but only
> by writing corresponding data pages, I'm not sure whether it is an actually
> good idea or not, but if we go the direction, we won't need pg_lesslog.
>
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center
>
>
>