Re: libpq compression

Florian G. Pflug <fgp@phlo.org>

From: Florian Pflug <fgp@phlo.org>

To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>

Cc: Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Euler Taveira <euler@timbira.com>, Marko Kreen <markokr@gmail.com>, Martijn van Oosterhout <kleptog@svana.org>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Claes Jakobsson <claes@versed.se>

Date: 2012-06-25T19:45:26Z

Lists: pgsql-hackers

On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Or that it takes less code/generates cleaner code...
> 
> So we're talking about some LZO things such as snappy from google, and
> that would be another run time dependency IIUC.
> 
> I think it's time to talk about fastlz:
> 
>  http://fastlz.org/
>  http://code.google.com/p/fastlz/source/browse/trunk/fastlz.c
> 
>  551 lines of C code under MIT license, works also under windows
> 
> I guess it would be easy (and safe) enough to embed in our tree should
> we decide going this way.

Agreed. If we extend the protocol to support compression, and not rely
on SSL, then let's pick one of these LZ77-style compressors, and let's
integrate it into our tree.

We should then also make it possible to enable compression only for
the server -> client direction. Since those types of compressions are
usually pretty easy to decompress, that reduces the amount to work
non-libpq clients have to put in to take advantage of compression.

best regards,
Florian Pflug