On Tue, Nov 8, 2011 at 14:59, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> I ran into a performance problem described in this thread:
>
> http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
> continued here:
> http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
>
> OpenSSL compresses data by default, and that causes a
> performance penalty of 100% and more, at least when
> SELECTing larger bytea objects.
> The backend process becomes CPU bound.
>
> From OpenSSL version 1.0.0. on, compression can be
> disabled. The attached patch does that, and with that
> patch I see dramatic performance improvements:
>
> Unpatched:
>
> samples % image name symbol name
> 6754 83.7861 libz.so.1.2.3 /lib64/libz.so.1.2.3
> 618 7.6665 libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.1.0.0
> 534 6.6245 postgres hex_encode
> 95 1.1785 libc-2.12.so memcpy
>
> Patched:
>
> samples % image name symbol name
> 751 50.1670 libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.1.0.0
> 594 39.6794 postgres hex_encode
> 83 5.5444 libc-2.12.so memcpy
>
> (the test case is selecting one 27 MB bytea in text
> mode over a localhost connection)
>
> Are there any objections to this?
This should probably be made an option.
And doesn't it, at least in a lot of cases, make more sense to control
this from the client side? It might typically be good to use
comopression if you are connecting over a slow link such as mobile or
satellite. And typically the client knows that, not the server. So
either client, or pg_hba driven, perhaps?
> 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?
Turning it off unconditionally can certainly create such a regression.
I don't think it's at all unrealstic.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/