Re: libpq compression

On 20-06-2012 17:40, Marko Kreen wrote:
> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug <fgp@phlo.org> wrote:
>> I'm starting to think that relying on SSL/TLS for compression of
>> unencrypted connections might not be such a good idea after all. We'd
>> be using the protocol in a way it quite clearly never was intended to
>> be used...
> 
> Maybe, but what is the argument that we should avoid
> on encryption+compression at the same time?
> 
> AES is quite lightweight compared to compression, so should
> be no problem in situations where you care about compression.
> 
If we could solve compression problem without AES that will turn things
easier. Compression-only via encryption is a weird manner to solve the problem
in the user's POV.

> RSA is noticeable, but only for short connections.
> Thus easily solvable with connection pooling.
> 
RSA overhead is not the main problem. SSL/TLS setup is.

> And for really special compression needs you can always
> create a UDF that does custom compression for you.
> 
You have to own the code to modify it; it is not always an option.

> So what exactly is the situation we need to solve
> with postgres-specific protocol compression?
> 
Compression only support. Why do I need to set up SSL/TLS just for compression?

IMHO SSL/TLS use is no different from relying in another library to handle
compression for the protocol and more it is compression-specific. That way, we
could implement another algorithms in such library without needing to modify
libpq code. Using SSL/TLS you are bounded by what SSL/TLS software products
decide to use as compression algorithms. I'll be happy to maintain the code
iif it is postgres-specific or even as close as possible to core.


-- 
   Euler Taveira de Oliveira - Timbira       http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento