Re: Zstandard support for toast compression

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Zstandard support for toast compression
Date: 2022-05-19 17:52:23
Message-ID: 3675390.dTIEYj77XG@thinkpad-pgpro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от вторник, 17 мая 2022 г. 23:01:07 MSK пользователь Tom Lane
написал:

Hi! I came to this branch looking for a patch to review, but I guess I would
join the discussion instead of reading the code.

> >> Yeah - I think we had better reserve the fourth bit pattern for
> >> something extensible e.g. another byte or several to specify the
> >> actual method, so that we don't have a hard limit of 4 methods. But
> >> even with such a system, the first 3 methods will always and forever
> >> be privileged over all others, so we'd better not make the mistake of
> >> adding something silly as our third algorithm.
> >
> > In such a situation, would they really end up being properly distinct
> > when it comes to what our users see..? I wouldn't really think so.
>
> It should be transparent to users, sure, but the point is that the
> first three methods will have a storage space advantage over others.
> Plus we'd have to do some actual work to create that extension mechanism.

Postgres is well known for extensiblility. One can write your own
implementation of almost everything and make it an extension.
Though one would hardly need more than one (or two) additional compression
methods, but which method one will really need is hard to say.

So I guess it would be much better to create and API for creating and
registering own compression method and create build in Zstd compression method
that can be used (or optionally not used) via that API.

Moreover I guess this API (may be with some modification) can be used for
seamless data encryption, for example.

So I guess it would be better to make it extensible from the start and use
this precious bit for compression method chosen by user, and may be later
extend it with another byte of compression method bits, if it is needed.

--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-05-19 17:59:21 Re: [RFC] Improving multi-column filter cardinality estimation using MCVs and HyperLogLog
Previous Message Christoph Berg 2022-05-19 17:20:05 Re: 15beta1 crash on mips64el in pg_regress/triggers