On 17.03.2018 17:18, Peter Eisentraut wrote:
On 3/11/18 13:28, Tom Lane wrote:
My proposal is the attached patch that sets the default in libpq to off
and adjusts the documentation a bit so it doesn't sound like we have
missed the news altogether.
Seems reasonable as far as it goes, but do we need to make corresponding
server-side changes?
We could add a setting to disable SSL compression on the server, as some
web servers have been doing, but the niche of version combinations where
that would be applicable seems pretty low.
One of our customers was managed to improve speed about 10 times by using SSL compression for the system where client and servers are located in different geographical regions
and query results are very large because of JSON columns. Them actually do not need encryption, just compression.
I expect that it is not the only case where compression of libpq protocol can be useful. Please notice that logical replication is also using libpq protocol.
If SSL compression is deprecated, should we provide own compression?
I have implemented some prototype implementation of it (patch is attached).
I have added compression=on/off parameter to connection string and -Z option to psql and pgbench utilities.
Below are some results:
Compression ratio (raw->compressed):
| libz (level=1)
| libzstd (level=1) |
pgbench -i -s 10
| 16997209->2536330
| 16997209->268077 |
pgbench -t 100000 -S
| 6289036->1523862
6600338<-900293
| 6288933->1777400
6600338<-1000318
|
There is no mistyping: libzstd compress COPY data about 10 times better than libz, with wonderful compression ratio 63.
Influence on execution time is minimal (I have tested local configuration when client and server are at the same host):
| no compression
| libz (level=1)
| libzstd (level=1) |
pgbench -i -s 10
| 1.552
| 1.572
| 1.611 |
pgbench -t 100000 -S
| 4.482
| 4.926
| 4.877
|
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company