From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: Pluggable toaster |
Date: | 2022-10-24 11:55:45 |
Message-ID: | CAJ7c6TNNROJcC0ObdeVRM9+kG2gYT+_RBzmf-xDhia5JeYfhGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-10-24 11:58:43 | Re: Perform streaming logical transactions by background workers and parallel apply |
Previous Message | Masahiko Sawada | 2022-10-24 11:42:13 | Re: Perform streaming logical transactions by background workers and parallel apply |