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

From Mark Cave-Ayland
Subject Re: Quick-and-dirty compression for WAL backup blocks
Date
Msg-id 9EB50F1A91413F4FA63019487FCD251D113395@WEBBASEDDC.webbasedltd.local
Whole thread Raw
In response to Re: Quick-and-dirty compression for WAL backup blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 04 June 2005 16:46
> To: Mark Cave-Ayland (External)
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: Quick-and-dirty compression for WAL backup blocks

(cut)

> 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.


Hi Tom,

Thanks for the numbers. I've just been across to the OSDL STP website and it
appears that the automatic nightly PostgreSQL CVS builds set up by Mark have
been broken since the middle of April :( A brief look shows that compilation
of the PostgreSQL sources is failing with lots of errors and warnings. I
don't think I can justify the time at the moment to go and look at this
myself, however I thought I'd post to -hackers as a heads up in case anyone
else could pick this up.


Kind regards,

Mark.

------------------------
WebBased Ltd
South West Technology Centre
Tamar Science Park
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023
W: http://www.webbased.co.uk




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Speeding up the Postgres lexer
Next
From: Richard Huxton
Date:
Subject: Re: thw rewriter and default values, again