Re: Pluggable toaster

Hi!

Aleksander, this is a good question.
If I understood you correctly, you mean that the alternative TOAST
mechanism B is using a specific
Table AM A?

Pluggable TOAST API was designed with storage flexibility in mind, and
Custom TOAST mechanics is
free to use any storage methods - we've tested it with some custom Toaster,
because it is completely
hidden from the caller, and is not limited to Heap, though extensions'
interdependencies is a very tricky
question, and surely not the one to be answered quickly.

Still, I have good news on this topic - I'm currently re-working Pluggable
TOAST in a more OOP-correct
way, generalizing Table to Toaster relation from column attribute and
reloptions with separate catalog table
describing Relation,Toaster and TOAST storage entities relations, with lazy
TOAST Tables creation for
the Generic Toaster, and dropping the limits of 1 TOAST table per relation.
In current implementation
Toaster OID and TOAST relation ID are stored as a part of Relation, which
is not the best solution, and
leaves some Toaster's nuts and bolts open to AM that uses it, and we
decided to hide this part into Toaster
too.

The next logical step is using Table AM API, if Table AM Routine is
provided to Toaster, instead of direct
calls to Heap AM methods.

This was thought of in the following way:
Table AM Routine is passed to Toaster as a parameter, and direct Heap calls
are replaced with the TAM
Routine calls. This is possible, but needs further investigation, because
TOAST manipulations with data
require, as it is seen from the first dive into TAM API, some extension of
this API.

I'll present the results of our research as soon as they're ready.

On Sat, Oct 22, 2022 at 11:58 AM Aleksander Alekseev <
aleksander(at)timescale(dot)com> wrote:

> Hi Nikita,
>
> > Aleksander, we have had this in mind while developing this feature, and
> have checked it. Just a slight modification is needed
> > to make it work with Pluggable Storage (Access Methods) API.
>
> Could you please clarify this a little from the architectural point of
> view?
>
> Let's say company A implements some specific TableAM (in-memory / the
> one that uses undo logging / etc). Company B implements an alternative
> TOAST mechanism.
>
> How the TOAST extension is going to work without knowing any specifics
> of the TableAM the user chooses for the given relation, and vice
> versa? How one of the extensions is going to upgrade / downgrade
> between the versions without knowing any implementation details of
> another?
>
> --
> Best regards,
> Aleksander Alekseev
>

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