On 11/08/2011 09:34 AM, Tom Lane wrote:
> Marko Kreen<markokr@gmail.com> writes:
>> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz<laurenz.albe@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
