From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Euler Taveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-14 19:38:02 |
Message-ID: | CAHyXU0wnD=FYzQB3Y=ouJkW9hAx8DeSydiXpibvMA-WavEcYFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | ktm@rice.edu | 2012-06-14 19:56:01 | Re: libpq compression |
Previous Message | Gurjeet Singh | 2012-06-14 19:36:12 | Re: Patch pg_is_in_backup() |