On Fri, 2010-08-13 at 11:38 -0400, Tom Lane wrote:
> Craig Ringer <craig@postnewspapers.com.au> writes:
> > Overall: it sounds to me like SSL/TLS level compression would only be
> > useful for native libpq-to-postgresql connections, and probably wouldn't
> > be usable for non-libpq based database access drivers. It'd only work if
> > SSL was configured, which is a limitation it'd be nice to avoid.
>
> 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.
It reduces congestion on networks, yes even 100 and 1000 networks.
It provides data to the client faster because there is reduced data to
push.
Compression is cheap even way back then because generally the data being
compressed is comparatively small. (Imagine how fast we compress with
CPUs that were just two years older)
Not really arguing with Tom's point as much as reminding people this has
been tested and proven as a benefit.
Also, let's not forget Mobile apps :D
http://archives.postgresql.org/pgsql-hackers/2002-12/msg00598.php
I say, let's DO IT! :)
Sincerely,
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt