Re: [PATCH] Compression dictionaries for JSONB

Поиск
Список
Период
Сортировка
От Nikita Malakhov
Тема Re: [PATCH] Compression dictionaries for JSONB
Дата
Msg-id CAN-LCVOgMrda9hOdzGkCMdwY6dH0JQa13QvPsqUwY57TEn6jww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Compression dictionaries for JSONB  (Aleksander Alekseev <aleksander@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: MERGE ... RETURNING
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Build the docs if there are changes in docs and don't run other tasks if the changes are only in docs