On Sat, Jun 04, 2005 at 11:46:07AM -0400, Tom Lane wrote:
> I've completed a test run for this (it's essentially MySQL's sql-bench
> done immediately after initdb). What I get is:
>
> CVS tip of 6/1: ending WAL offset = 0/A364A780 = 2741282688 bytes written
>
> CVS tip of 6/2: ending WAL offset = 0/8BB091DC = 2343604700 bytes written
>
> or about a 15% savings. This is with a checkpoint_segments setting of 30.
> One can presume that the savings would be larger at smaller checkpoint
> intervals and smaller at larger intervals, but I didn't try more than
> one set of test conditions.
>
> I'd say that's an improvement worth having, especially considering that
> it requires no net expenditure of CPU time. But the table is certainly
> still open to discuss more complicated approaches.
If it's not hard to hack in as a test, it'd be interesting to see what
additional gains a more aggresive compression algorithm like LZW got.
CPU is more of a concern in that case, but for databases generating a
lot of WAL it might still be a win.
BTW, is this the thread you reffered to? I wasn't able to find it in the
TODO and had to go into the archives to find it...
http://archives.postgresql.org/pgsql-performance/2005-04/msg00264.php
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"