On Fri, 13 May 2022 at 10:09, Aleksander Alekseev <aleksan...@timescale.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.
