Re: Quick-and-dirty compression for WAL backup blocks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Quick-and-dirty compression for WAL backup blocks
Date
Msg-id 13591.1117635154@sss.pgh.pa.us
Whole thread Raw
In response to Quick-and-dirty compression for WAL backup blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Quick-and-dirty compression for WAL backup blocks
List pgsql-hackers
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes:
> I also noticed your comment above that mentioned that compression would be
> less effective as the pages became more full. Would changing the loading
> factor of database pages have an effect here, as I would have thought that
> the WAL would be fsync'd more aggressively than the heap?

Yeah, it's predictable that leaving more free space per page would make
the optimization more effective.  I don't have anything quantitative to
say about it.

> If you do manage to go ahead with the code, I'd be very interested to see
> some comparisons in bytes written to XLog for old and new approaches for
> some inserts/updates. Perhaps we could ask Mark to run another TPC benchmark
> at OSDL when this and the CRC changes have been completed.

Good idea.  One point is that the larger the checkpoint interval, the
less this matters at all, because a backup block is only written for
a given page the first time it is modified after a checkpoint.  (This
is one of the big reasons frequent checkpoints are expensive.)  IIRC
Mark was using unrealistically large checkpoint intervals, which would
mean he'd underestimate the effects of optimizing backup blocks.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: NOLOGGING option, or ?
Next
From: Bruce Momjian
Date:
Subject: Re: NOLOGGING option, or ?