Re: libpq compression

On Thu, Jun 14, 2012 at 10:14 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Jun14, 2012, at 15:28 , Euler Taveira wrote:
>> On 14-06-2012 02:19, Tom Lane wrote:
>>> I still think that pushing this off to openssl (not an ssh tunnel, but
>>> the underlying transport library) would be an adequate solution.
>>> If you are shoving data over a connection that is long enough to need
>>> compression, the odds that every bit of it is trustworthy seem pretty
>>> small, so you need encryption too.
>>>
>> I don't want to pay the SSL connection overhead. Also I just want compression,
>> encryption is not required. OpenSSL give us encryption with/without
>> compression; we need an option to obtain compression in non-SSL connections.
>
> AFAIR, openssl supports a NULL cipher which doesn't do any encryption. We
> could have a connection parameter, say compress=on, which selects that
> cipher (unless sslmode is set to prefer or higher, of course).
>
> SSL NULL-chipher connections would be treated like unencrypted connections
> when matching against pg_hba.conf.
>
> best regards,
> Florian Pflug
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

It doesn't sound like there is a lot of support for this idea, but I
think it would be nice to get something like lz4
(http://code.google.com/p/lz4/) or snappy
(http://code.google.com/p/snappy/) support. Both are BSD-ish licensed.
It could be useful for streaming replication as well. A hook (as Euler
mentioned) might be a nice compromise.