Re: libpq compression

On 08.02.2019 12:33, Daniel Gustafsson wrote:
>> On 8 Feb 2019, at 10:15, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
>> Frankly speaking, I do not think that such flexibility in choosing compression algorithms is really needed.
>> I do not expect that there will be many situations where old client has to communicate with new server or visa
versa.
>> In most cases both client and server belongs to the same postgres distributive and so implements the same
compressionalgorithm.
 
>> As far as we are compressing only temporary data (traffic), the problem of providing backward compatibility seems to
benot so important.
 
> I don’t think this assumption is entirely valid, and would risk unnecessary
> breakage.

I am also not sure in this assumption. We (PostgresPro) are having some 
issues now with CFS (file level compression of Postgres database).
Some build are using zstd, some are using zlib (default)...
zstd is faster and provides better compression ratio and is available at 
most platforms.
But zlib is available almost everywhere and is used by Postgres by 
default...
The only thing I know for sure: if we implement several algorithms and 
make it possible for database user to make a choice, then
we will get much more problems.

Right now Postgres is using zlib as the only supported compression 
algorithm in many places.
So may be libpq compression should also use only zlib and provide no 
other choices?

Concerning backward compatibility. Assume that we allow use zstd, but 
then Facebook change zstd license or some critical bug in it is found.
So we will have to exclude dependency on zstd. So there will be no 
backward compatibility in any case, even if we support more 
sophisticated negotiation between client and server in choosing 
compression algorithm.

What can be more interesting - is to support custom compression 
algorithms (optimized for the particular data flow).
But it seems to be completely different and much more sophisticated 
story. We have to provide some mechanism for loading foreign libraries 
at client side!
IMHO it is overkill.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company