From: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-14 19:56:01 |
Message-ID: | 20120614195601.GD6547@aart.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)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". It would be far better all
> > around if we supported exactly one, well-chosen, method. But really
> > I still don't see a reason not to let openssl do it for us.
>
> 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.
>
> merlin
>
+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.
Regards,
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-14 20:13:17 | Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture |
Previous Message | Merlin Moncure | 2012-06-14 19:38:02 | Re: libpq compression |