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 [EMAIL PROTECTED] 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?" ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly