Re: Disable OpenSSL compression - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Disable OpenSSL compression
Date
Msg-id CACMqXC+D2doCOEn3tcTuz4Gf91AwOwpc1U_rs1JF9no2yUeCgQ@mail.gmail.com
Whole thread Raw
In response to Re: Disable OpenSSL compression  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> 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.

+1 for keeping current default.

But I can imagine scenarios where having option to turn compression
off could be useful:
- when minimal latency is required
- when "normal" latency is required, but data is big
- when serving big non-compressible blobs - zlib can be very slow
- when serving lots of connections and want to minimize unnecessary cpu and memory load

Depending on how zlib is used by openssl, some of
them may not happen in practice.

--
marko


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Disable OpenSSL compression
Next
From: Tom Lane
Date:
Subject: Re: DatumGetInetP buggy