On Fri, Jun 15, 2012 at 12:48:24PM +0200, Florian Pflug wrote: > > Yeah, but that alone is IMO a rather big blocker for claiming that > > this is the only way to do it :( And I think the fact that that > > wikipedia page doesn't list any other ones, is a sign that there might > > not be a lot of other choices out there in reality - expecially not > > opensource… > > Hm, but things get even harder for the JDBC and .NET folks if we go > with a third-party compression method. Or would we require that the > existence of a free Java (and maybe .NET) implementation of such a > method would be an absolute must? > > The way I see it, if we use SSL-based compression then non-libpq clients > there's at least a chance of those clients being able to use it easily > (if their SSL implementation supports it). If we go with a third-party > compression method, they *all* need to add yet another dependency, or may > even need to re-implement the compression method in their implementation > language of choice.
Does OpenSSL use hardware acceleration for its compression? I know it often does for encryption --- that would be a big reason to do compression at the SSL layer. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
