Re: [PATCH] Compression dictionaries for JSONB - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: [PATCH] Compression dictionaries for JSONB
Date
Msg-id CAN-LCVOgMrda9hOdzGkCMdwY6dH0JQa13QvPsqUwY57TEn6jww@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Compression dictionaries for JSONB  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi,

Aleksander, there was a quite straightforward answer regarding Pluggable TOAST
in other thread - the Pluggable TOAST feature is not desired by the community,
and advanced TOAST mechanics would be accepted as parts of problematic
datatypes extended functionality, on a par with in and out functions, so what I am
actually doing now - re-writing JSONb TOAST improvements to be called as separate
functions without Pluggable TOAST API. This takes some time because there is a large
and complex code base left by Nikita Glukhov who has lost interest in this work due
to some reasons.

I, personally, think that these two features could benefit from each other, but they could
be adapted to each other after I would introduce JSONb Toaster in v17 master.

If you don't mind please check the thread on extending the TOAST pointer - it is important
for improving TOAST mechanics.


On Wed, Jan 17, 2024 at 5:27 PM Aleksander Alekseev <aleksander@timescale.com> wrote:
Hi again,

> Yes it does for a while now. Until we reach any agreement regarding
> questions (1) and (2) personally I don't see the point in submitting
> rebased patches. We can continue the discussion but mark the CF entry
> as RwF for now it will be helpful.

Sorry, what I actually meant were the following questions:

"""
Several things occured to me:

- Does anyone believe that va_tag should be part of the utf8-like
bitmask in order to save a byte or two?

- The described approach means that compression dictionaries are not
going to be used when data is compressed in-place (i.e. within a
tuple), since no TOAST pointer is involved in this case. Also we will
be unable to add additional compression algorithms here. Does anyone
have problems with this? Should we use the reserved compression
algorithm id instead as a marker of an extended TOAST?

- It would be nice to decompose the feature in several independent
patches, e.g. modify TOAST first, then add compression dictionaries
without automatic update of the dictionaries, then add the automatic
update. I find it difficult to imagine however how to modify TOAST
pointers and test the code properly without a dependency on a larger
feature. Could anyone think of a trivial test case for extendable
TOAST? Maybe something we could add to src/test/modules similarly to
how we test SLRU, background workers, etc.
"""

Since there was not much activity since then (for 3 months) I don't
really see how to process further.

--
Best regards,
Aleksander Alekseev


--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: MERGE ... RETURNING
Next
From: Daniel Gustafsson
Date:
Subject: Re: Build the docs if there are changes in docs and don't run other tasks if the changes are only in docs