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
