pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Euler Taveira <euler@timbira.com>
To: Marko Kreen <markokr@gmail.com>
Cc: Florian Pflug <fgp@phlo.org>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Claes Jakobsson <claes@versed.se>
Subject: Re: libpq compression
Date: Fri, 22 Jun 2012 13:38:20 -0300
Message-ID: <4FE49F7C.9020300@timbira.com> (raw)
In-Reply-To: <CACMqXCLkOpYnK1eLTb_bAqx344C9j=rchTeNXSW=E6+hdXwyPA@mail.gmail.com>
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>

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



view thread (289+ messages)  latest in thread

Message-ID: <4FE49F7C.9020300@timbira.com>
Permalink:  ../4FE49F7C.9020300@timbira.com/
Also on:    postgresql.org/message-id/4FE49F7C.9020300@timbira.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: euler@timbira.com, markokr@gmail.com, fgp@phlo.org, magnus@hagander.net, robertmhaas@gmail.com, kleptog@svana.org, tgl@sss.pgh.pa.us, bruce@momjian.us, claes@versed.se
  Subject: Re: libpq compression
  In-Reply-To: <4FE49F7C.9020300@timbira.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox