From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Iwata, Aya <iwata.aya@jp.fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: rharwood@redhat.com <rharwood@redhat.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: g.smolkin@postgrespro.ru <g.smolkin@postgrespro.ru>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Subject: Re: libpq compression
Date: Fri, 8 Feb 2019 19:33:53 +0300
Message-ID: <b200c179-1d4e-8ff1-b8bd-3900365412b6@postgrespro.ru> (raw)
In-Reply-To: <A72D525A-5DB2-41E2-98E8-25CC6649AC1E@yesql.se>
References: <CAEepm=3CGUX4Vyw=jFaOedt99HS1HQiBKYTX4OYHo7HU2AczZg@mail.gmail.com>
<CAEepm=3RAS8xVQK8rs+Xitzp+JXzGdGsMA7f+H8fjKQ7Do8aSA@mail.gmail.com>
<f4ad0809-dd90-e321-5c1a-0ca68a136a8f@postgrespro.ru>
<jlg4lhzdeak.fsf@redhat.com>
<b630ffe2-f61f-ff2e-7f9c-2f4cdbfd3380@postgrespro.ru>
<1eca5819-2b58-e929-1bf3-2d4dadf491b9@2ndQuadrant.com>
<CA+Tgmob08ikN03bZGgrf=nUAYkZ2-ZuRuWqP-BBkUq9v_AEw=Q@mail.gmail.com>
<8d9386be-a567-c526-2fc1-153d6ffd3507@2ndQuadrant.com>
<17747c8b-c088-6f92-38e9-98316910202a@postgrespro.ru>
<20181001064903.GG11712@paquier.xyz>
<c79ff1a0-d2c7-c513-598e-f9658329654b@postgrespro.ru>
<CA+q6zcVaT=m-Py-R2ap0oZDEWxUkKR9hFqDpVNNtHTGTkbd75g@mail.gmail.com>
<71E660EB361DF14299875B198D4CE5423DEB752E@g01jpexmbkw25>
<1b2d418b-f3b1-620e-8456-145d6e943da6@postgrespro.ru>
<71E660EB361DF14299875B198D4CE5423DED67E5@g01jpexmbkw25>
<dae47f7a-9e33-8cba-859c-dbd39bebe218@postgrespro.ru>
<A72D525A-5DB2-41E2-98E8-25CC6649AC1E@yesql.se>
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 compression algorithm.
>> As far as we are compressing only temporary data (traffic), the problem of providing backward compatibility seems to be not 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: k.knizhnik@postgrespro.ru, daniel@yesql.se, iwata.aya@jp.fujitsu.com, michael@paquier.xyz, andrew.dunstan@2ndquadrant.com, robertmhaas@gmail.com, rharwood@redhat.com, thomas.munro@enterprisedb.com, g.smolkin@postgrespro.ru, pgsql-hackers@lists.postgresql.org, 9erthalion6@gmail.com
Subject: Re: libpq compression
In-Reply-To: <b200c179-1d4e-8ff1-b8bd-3900365412b6@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox