From: Tom Lane <tgl@sss.pgh.pa.us>
To: Euler Taveira <euler@timbira.com>
cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
In-reply-to: <4FD9E70B.9040607@timbira.com>
References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us>
	<4FD9E70B.9040607@timbira.com>
Comments: In-reply-to Euler Taveira <euler@timbira.com>
	message dated "Thu, 14 Jun 2012 10:28:43 -0300"
Date: Thu, 14 Jun 2012 14:43:04 -0400
Message-ID: <11502.1339699384@sss.pgh.pa.us>

Euler Taveira <euler@timbira.com> writes:
> On 14-06-2012 02:19, Tom Lane wrote:
>> ...  I especially think that importing bzip2
>> is a pretty bad idea --- it's not only a new dependency, but bzip2's
>> compression versus speed tradeoff is entirely inappropriate for this
>> use-case.

> I see, the idea is that bzip2 would be a compiled-in option (not enabled by
> default) just to give another compression option.

I'm not particularly thrilled with "let's have more compression options
just to have options".  Each such option you add is another source of
fail-to-connect incompatibilities (when either the client or the server
doesn't have it).  Moreover, while there are a lot of compression
algorithms out there, a lot of them are completely unsuited for this
use-case.  If memory serves, bzip2 for example requires fairly large
data blocks in order to get decent compression, which means you are
either going to get terrible compression or suffer very bad latency
when trying to apply it to a connection data stream.

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.

			regards, tom lane