public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matthias van de Meent <[email protected]>
To: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Nikita Malakhov <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Teodor Sigaev <[email protected]>
Subject: Re: Pluggable toaster
Date: Mon, 6 Feb 2023 21:14:54 +0100
Message-ID: <CAEze2WhRJwr7MhkcckxpOAR5=6gUQQQmVdfPtvNu-u8J8RkzmA@mail.gmail.com> (raw)
In-Reply-To: <CAJ7c6TMZ7xySLzhygvzezPysyM5aZ6OjO8zHSUTO+GMBeL1a3g@mail.gmail.com>
References: <CAN-LCVMV3m+pzSDqOLyzgVRXA2zJ94n_T7kyAc2Z5JJpH018sA@mail.gmail.com>
<[email protected]>
<CAN-LCVOv5is9dUn1U3KYy4hAhVK7tx6a7goOFmgbrGM7ZSAxRA@mail.gmail.com>
<CAJ7c6TMZ7xySLzhygvzezPysyM5aZ6OjO8zHSUTO+GMBeL1a3g@mail.gmail.com>
On Mon, 6 Feb 2023 at 15:38, Aleksander Alekseev
<[email protected]> 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
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Pluggable toaster
In-Reply-To: <CAEze2WhRJwr7MhkcckxpOAR5=6gUQQQmVdfPtvNu-u8J8RkzmA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox