On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane <t...@sss.pgh.pa.us> 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.
+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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
