On Thu, 26 Oct 2023 at 15:18, Aleksander Alekseev <aleksan...@timescale.com> wrote: > > Hi, > > > And the goal of *THIS* topic is to gather a picture on how the community > > sees > > improvements in TOAST mechanics if it doesn't want it the way we proposed > > before, to understand which way to go with JSON advanced storage and other > > enhancements we already have. Previous topic was not of any help here. > > Publish your code under an appropriate license first so that 1. anyone > can test/benchmark it and 2. merge it to the PostgreSQL core if > necessary. > > Or better consider participating in the [1] discussion where we > reached a consensus on RFC and are working on improving TOAST for JSON > and other types. We try to be mindful of use cases you named before > like 64-bit TOAST pointers but we still could use your input.
I feel that the no. 2 proposal is significantly different from the discussion over at [1] in that it concerns changes in the interface between types and toast, as opposed to as opposed to the no. 1 proposal (and [1]'s) changes that stay mostly inside the current TOAST apis and abstractions. The "Compression dictionaries for JSONB" thread that you linked went the way of "store and use compression dictionaries for TOAST compression algorithms", which is at a lower level than one of the other ideas, which was to "allow JSONB to use a dictionary of common values to dictionary-encode some of the contained entries". Naive compression of the Datum's bytes makes the compressed datum unparseable without decompression, even when dictionaries are used to decrease the compressed size, while a type's own compression dictionary substitutions could allow it to maintain it's structure and would thus allow for a lower memory and storage footprint of the column's datums during query processing. Kind regards, Matthias van de Meent Neon (https://neon.tech)
