On 11/08/2011 09:34 AM, Tom Lane wrote:
Marko Kreen<mark...@gmail.com> writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz<laurenz.a...@wien.gv.at> wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic scenario?
Yes, it's a realistic scenario. Please make it a option.
I distinctly recall us getting bashed a few years ago because there
wasn't any convenient way to turn SSL compression *on*. Now that SSL
finally does the sane thing by default, you want to turn it off?
The fact of the matter is that in most situations where you want SSL,
ie links across insecure WANs, compression is a win. Testing a local
connection, as you seem to have done, is just about 100% irrelevant to
performance in the real world.
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
evidence that it's useful over non-local connections.
I can certainly conceive of situations where one wants SSL on a high
speed/bandwidth network. I don't think we should assume that all or even
most real world SSL use will be across slow networks.
Here's another data point:
<http://journal.paul.querna.org/articles/2011/04/05/openssl-memory-use/>
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
