Re: libpq compression

On Thu, Jun 14, 2012 at 02:43:04PM -0400, Tom Lane wrote:
> 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.

Do we just need to document SSL's NULL encryption option?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +