| From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marko Kreen" <markokr(at)gmail(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Disable OpenSSL compression |
| Date: | 2011-11-08 15:19:02 |
| Message-ID: | D960CB61B694CF459DCFB4B0128514C20713F535@exadv11.host.magwien.gv.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
Maybe that's paranoia, but we use SSL via the company's LAN to keep
potentially sensitive data from crossing the network unencrypted.
> 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 will try to provide test results via remote connection; I thought
that localhost was a good enough simulation for a situation where
you are not network bound.
I agree with you that a client option would make more sense.
The big problem I personally have with that is that it only works
if you use libpq. When using the JDBC driver or Npgsql, a client
option wouldn't help me at all.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-11-08 15:26:36 | Re: heap vacuum & cleanup locks |
| Previous Message | Robert Haas | 2011-11-08 15:16:17 | Re: heap vacuum & cleanup locks |