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 < aleksan...@timescale.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/
