Date: Thu, 14 Jun 2012 14:56:01 -0500
From: "ktm@rice.edu" <ktm@rice.edu>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira <euler@timbira.com>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
Message-ID: <20120614195601.GD6547@aart.rice.edu>
References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us>
	<4FD9E70B.9040607@timbira.com> <11502.1339699384@sss.pgh.pa.us>
	<CAHyXU0wnD=FYzQB3Y=ouJkW9hAx8DeSydiXpibvMA-WavEcYFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: 
 <CAHyXU0wnD=FYzQB3Y=ouJkW9hAx8DeSydiXpibvMA-WavEcYFQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 14, 2012 at 02:38:02PM -0500, Merlin Moncure wrote:
> On Thu, Jun 14, 2012 at 1:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > So I've got very little patience with the idea of "let's put in some
> > hooks and then great things will happen". =A0It would be far better a=
ll
> > around if we supported exactly one, well-chosen, method. =A0But reall=
y
> > I still don't see a reason not to let openssl do it for us.
>=20
> Well, for toast compression the right choice is definitely one of the
> lz based algorithms (not libz!).  For transport compression you have
> the case of sending large data over very slow and/or expensive links
> in which case you want to use bzip type methods.  But in the majority
> of cases I'd probably be using lz there too.  So if I had to pick just
> one, there you go.  But which one? the lz algorithm with arguably the
> best pedigree (lzo) is gnu but there are many other decent candidates,
> some of which have really tiny implementations.
>=20
> merlin
>=20

+1 for a very fast compressor/de-compressor. lz4 from Google has
a BSD license and at 8.5X faster compression than zlib(-1) and
5X faster de-compression the zlib (-1), 2X faster than LZO even
would be my pick.=20

Regards,
Ken