Re: [PATCH] Compression dictionaries for JSONB

On Fri, 13 May 2022 at 10:09, Aleksander Alekseev
<aleksander(at)timescale(dot)com> wrote:
>
> Hi hackers,
>
> > Here it the 2nd version of the patch:
> >
> > - Includes changes named above
> > - Fixes a warning reported by cfbot
> > - Fixes some FIXME's
> > - The path includes some simple tests now
> > - A proper commit message was added
>
> Here is the rebased version of the patch. Changes compared to v2 are minimal.
>
> > Open questions:
> > - Dictionary entries are currently stored as NameData, the same type that is
> > used for enums. Are we OK with the accompanying limitations? Any alternative
> > suggestions?
> > - All in all, am I moving the right direction?
>
> I would like to receive a little bit more feedback before investing more time
> into this effort. This will allow me, if necessary, to alter the overall design
> more easily.

Sorry for the delayed reply. After the last thread, I've put some time
in looking into the "pluggable toaster" patches, which appears to want
to provide related things: Compressing typed data using an extensible
API. I think that that API is a better approach to increase the
compression ratio for JSONB.

That does not mean that I think that the basis of this patch is
incorrect, just that the current API (through new entries in the
pg_type and pg_casts catalogs) is not the right direction if/when
we're going to have a pluggable toaster API. The bulk of the patch
should still be usable, but I think that the way it interfaces with
the CREATE TABLE (column ...) APIs would need reworking to build on
top of the api's of the "pluggable toaster" patches (so, creating
toasters instead of types). I think that would allow for an overall
better user experience and better performance due to decreased need
for fully decompressed type casting.

Kind regards,

Matthias van de Meent.