Re: Pluggable toaster

Hi,

>This is exactly the point. In order to not to create a silver bullet,
>TOASTers should be limited to a single TableAM. The one we know uses
>pages of a known fixed size, the one that actually requires TOAST
>because pages are relatively small, etc.

Currently all our TOAST implementations use Heap AM, except ones
that use external (truly external, i.e. files outside DB) storage. Using
Table AM
Routine and routing AM methods calls via it is a topic for further
discussion,
if Pluggable TOAST will be committed. And even then it would be an open
issue.

>I believe this is the source of misunderstanding. Note that not _any_
>TableAM needs TOAST to begin with. As an example, if one chooses to
>implement a column-organized TableAM that stores all text/bytea
>attributes in a separate dictionary file this person doesn't need
>TOAST and doesn't want to be constrained by the need of choosing one.

>For this reason the "N TOASTers x M TableAMs" approach is
>architecturally broken.

TOAST implementation is not necessary for Table AM. And TOAST API is just
an optional open interface - SET TOASTER is an option for CREATE/ALTER
TABLE command. In previous discussion we haven't mentioned an approach
"N TOASTers x M TableAMs".

>To clarify: is an ability to specify TOASTers for given columns and/or
>types also part of the plan?

For table columns it is already supported by the syntax part of the TOAST
API.
For data types we reserved the validation part of the API, but this support
is still a
subject for discussion, although we think it will be very handy for DB
users, like
we issue something like:
CREATE TYPE ... TOASTER=jsonb_toaster ... ;
or
ALTER TYPE JSONB SET TOASTER jsonb_toaster;
and do not have to set special toaster for jsonb column each time we create
or alter a table with it.

>No. To be honest, it looks like you are merely discarding most/any
>feedback the community provided so far.

Very sorry to read that. Almost all of the requests in this discussion have
been taken
into account in patches, and the most serious one - I mean pg_attribute
expansion
which was mentioned by Tom Lane and Robert Haas - is being fixed right now
and
will be ready very soon.

>I really think that pluggable TOASTers would be a great feature.
>However if the goal is to get it into the core I doubt that we are
>going to make much progress with the current approach.

We hope we will. This feature is very demanded by end-users, and will be
even more
as time goes by - current TOAST limitations and how they affect DBMS
performance is
a serious drawback in comparison to competitors.

On Mon, Oct 24, 2022 at 2:55 PM Aleksander Alekseev <
aleksander(at)timescale(dot)com> wrote:

> Hi Nikita,
>
> > >I don't argue with most of what you say. I am just pointing out the
> > >reason why the chosen approach "N TOASTers x M TableAMs" will not
> > >work:
> >
> > We assume that TAM used in custom Toaster works as it is should work,
> > and leave TAM internals to this TAM developer - say, we do not want to
> > change internals of Heap AM.
> >
> > We don't want to create some kind of silver bullet.
>
> This is exactly the point. In order to not to create a silver bullet,
> TOASTers should be limited to a single TableAM. The one we know uses
> pages of a known fixed size, the one that actually requires TOAST
> because pages are relatively small, etc.
>
> > That's what the TOAST API is - just an interface that all custom
> > TOAST implementations use to have a common entry point from any TAM,
> > [...]
>
> I believe this is the source of misunderstanding. Note that not _any_
> TableAM needs TOAST to begin with. As an example, if one chooses to
> implement a column-organized TableAM that stores all text/bytea
> attributes in a separate dictionary file this person doesn't need
> TOAST and doesn't want to be constrained by the need of choosing one.
>
> For this reason the "N TOASTers x M TableAMs" approach is
> architecturally broken.
>
> > keep in mind that different kinds of data require very
> > different approach to external storage - say, JSON TOAST works with
> > maps of keys and values, [...]
>
> To clarify: is an ability to specify TOASTers for given columns and/or
> types also part of the plan?
>
> > Have I answered your question? Please don't hesitate to point to any
> unclear
> > parts, I'd be glad to explain that.
>
> No. To be honest, it looks like you are merely discarding most/any
> feedback the community provided so far.
>
> I really think that pluggable TOASTers would be a great feature.
> However if the goal is to get it into the core I doubt that we are
> going to make much progress with the current approach.
>
> --
> Best regards,
> Aleksander Alekseev
>

--
Regards,
Nikita Malakhov
Postgres Professional
https://postgrespro.ru/