Re: RFC: compression dictionaries for JSONB

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: RFC: compression dictionaries for JSONB
Date: 2021-10-08 17:17:39
Message-ID: CAEze2Wj61ZxpnxwdpQcsDQtzOhpKrSUCt5QX9O9xCFkg3a-Htg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 8 Oct 2021 at 17:19, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2021-Oct-08, Matthias van de Meent wrote:
>
> > On Fri, 8 Oct 2021 at 11:47, Aleksander Alekseev
> > <aleksander(at)timescale(dot)com> wrote:
>
> > > In order to do this, the SQL syntax should be modified. The proposed
> > > syntax is based on Matthias van de Meent's idea [6]:
> >
> > Seems fine
> >
> > > ```
> > > CREATE TYPE <type-name> AS JSONB_DICTIONARY (
> > > learn_by = { {"table_a", "column_a"}, {"table_b", "column_b"}, ... },
>
> Actually, why is it a JSONB_DICTIONARY and not like
>
> CREATE TYPE name AS DICTIONARY (
> base_type = JSONB, ...
> );

That's a good point, but if we're extending this syntax to allow the
ability of including other types, then I'd instead extend the syntax
that of below, so that the type of the dictionary entries is required
in the syntax:

CREATE TYPE name AS DICTIONARY OF jsonb [ ( ...entries ) ] [ WITH (
...options ) ];

> so that it is possible to use the infrastructure for other things? For
> example, perhaps PostGIS geometries could benefit from it -- or even
> text or xml columns.
>
> The pg_type entry would have to provide some support procedure that
> makes use of the dictionary in some way. This seems better than tying
> the SQL object to a specific type.

Agreed, but this might mean that much more effort would be required to
get such a useful quality-of-life feature committed.

Kind regards,

Matthias

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-10-08 17:21:31 Re: Parallel vacuum workers prevent the oldest xmin from advancing
Previous Message Bossart, Nathan 2021-10-08 17:11:12 Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?