On Fri, Aug 13, 2010 at 10:56 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Fri, 2010-08-13 at 11:38 -0400, Tom Lane wrote:
>>
>> I don't really see that. The case where it's sensible to use
>> compression on the connection is where you're pushing data across
>> a WAN. That's also pretty much exactly the situation where it's
>> sensible to use encryption. I guess there'd be a use case for
>> compression-without-encryption if you had a trustworthy private WAN,
>> but who's got one of those?
>>
>> So I'm much more in favor of doing something like this than doing it
>> directly in our own protocol.
>
> Well as a company who implemented compression for postgresql on the wire
> long ago :D. I can say it is actually useful as a whole. Even on private
> networks.
We use a SSH tunnel with compression over a 2MB/s link (IPSEC VPN)
from a production site to a DR site. We run slony over it and it
works quite well. From what I can tell, average about 95%
compression. This effectively gives us a 40MB/s link for replication.
We created a Solaris SMF service to maintain the SSH tunnel and a
restricted shell on the remote end. SSH connects with a private key.
SMF for slony has required dependencies on the local postgresql and
the SSH tunnel, so it all starts up and shutdowns down in the proper
sequence.
The SSH client created one forward port tunnel and one reverse port
tunnel, both on localhost. To abuse the tunnel one would have to
already be on the database server(s), so it seems (famous last words?)
fairly secure.
I think that adding compression to the SSL layer in Postgresql's wire
protocol would be great. We could eliminate our kludgey tunnel (aka,
yet another failure point).
Just my $0.02...