Message-ID: <4FE49F7C.9020300@timbira.com>
Date: Fri, 22 Jun 2012 13:38:20 -0300
From: Euler Taveira <euler@timbira.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Marko Kreen <markokr@gmail.com>
CC: Florian Pflug <fgp@phlo.org>, Magnus Hagander <magnus@hagander.net>,
	Robert Haas <robertmhaas@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>
Subject: Re: libpq compression
References: 
 <CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<4FDB954F.9010606@timbira.com> <5136.1339799120@sss.pgh.pa.us>
	<5365.1339799869@sss.pgh.pa.us>
	<CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
	<11357.1339822502@sss.pgh.pa.us>
	<CABUevEy1sUTOeCjNicUggnMpT7MfgjWud8kQ=wkvJsfbCU8=WQ@mail.gmail.com>
	<19804.1339859730@sss.pgh.pa.us>
	<9B10BD6E-31AA-4699-BB67-5C386B623F77@phlo.org>
	<27043.1339950593@sss.pgh.pa.us> <20120618174233.GA24681@svana.org>
	<CA+TgmoaTMxcAFMN8d_FXD1S_3keyq3a=Vwa7ka8cnVepy-jqjg@mail.gmail.com>
	<1D8B2B60-F42E-448C-9295-C07FACCF0611@phlo.org>
	<CABUevEybu+v7zcsM8qtOEFdQ95njyK=ERjVbdMAe3c7T2Ut6JA@mail.gmail.com>
	<7760EC03-5B38-4903-AD2D-95F787B1E1ED@phlo.org>
	<CACMqXCLkOpYnK1eLTb_bAqx344C9j=rchTeNXSW=E6+hdXwyPA@mail.gmail.com>
In-Reply-To: 
 <CACMqXCLkOpYnK1eLTb_bAqx344C9j=rchTeNXSW=E6+hdXwyPA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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