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