Re: Disable OpenSSL compression
| От | Marko Kreen |
|---|---|
| Тема | Re: Disable OpenSSL compression |
| Дата | |
| Msg-id | CACMqXC+D2doCOEn3tcTuz4Gf91AwOwpc1U_rs1JF9no2yUeCgQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Disable OpenSSL compression (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: