From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal to use JSON for Postgres Parser format |
Date: | 2022-09-20 15:28:57 |
Message-ID: | 20220920152857.5o7oqp7exv35fdwj@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Sep-20, Matthias van de Meent wrote:
> Allow me to add: compressability
>
> In the thread surrounding [0] there were complaints about the size of
> catalogs, and specifically the template database. Significant parts of
> that (688kB of 8080kB a fresh PG14 database) are in pg_rewrite, which
> consists mostly of serialized Nodes. If we're going to replace our
> current NodeToText infrastructure, we'd better know we can effectively
> compress this data.
True. Currently, the largest ev_action values compress pretty well. I
think if we wanted this to be more succint, we would have to invent some
binary format -- perhaps something like Protocol Buffers: it'd be stored
in the binary format in catalogs, but for output it would be converted
into something easy to read (we already do this for
pg_statistic_ext_data for example). We'd probably lose compressibility,
but that'd be okay because the binary format would already remove most
of the redundancy by nature.
Do we want to go there?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-09-20 15:51:05 | Re: [PATCH]Feature improvement for MERGE tab completion |
Previous Message | Ajin Cherian | 2022-09-20 14:57:44 | Re: Support logical replication of DDLs |