On Mon, 6 Feb 2023 at 15:38, Aleksander Alekseev <aleksan...@timescale.com> wrote: > I would like to point out however that there were several other pieces > of feedback that could have been missed: > > * No one wants to see this as an extension. This was my original > proposal (adding ZSON to /contrib/) and it was rejected. The community > explicitly wants this to be a core feature with its syntax, > autocompletion, documentation and stuff.
I believe that is a misrepresentation of the situation. ZSON had (has?) several systemic issues and could not be accepted to /contrib/ in the way it was implemented, and it was commented that it would make sense that the feature of compression assisted by dictionaries would be implemented in core. Yet still, that feature is only closely related to pluggable TOAST, but it is not the same as making TOAST pluggable. > * The community wants the feature to have a simple implementation. You > said yourself that the idea of type-aware TOASTers is very invasive, > and I completely agree. I'm not sure that this is correct either. Compression (and TOAST) is inherently complex, and I don't think we should reject improvements because they are complex. The problem that I see being raised here, is that there was little discussion and no observed community consensus about the design of this complex feature *before* this patch with high complexity was provided. The next action that was requested is to take a step back and decide how we would want to implement type-aware TOASTing (and the associated patch compression dictionaries) *before* we look into the type-aware toasting. > * People also want this to be simple from the user perspective, as > simple as just CREATE COMPRESSED TABLE ... [USING lz4|zstd]; Could you provide a reference to this? I have yet to see a COMPRESSED TABLE feature or syntax, let alone users asking for TOAST to be as easily usable as that feature or syntax. Kind regards, Matthias van de Meent
