Re: Pluggable toaster - Mailing list pgsql-hackers
| From | Nikita Malakhov |
|---|---|
| Subject | Re: Pluggable toaster |
| Date | |
| Msg-id | CAN-LCVOg4Yt1twJOMefnHAnh07FgoxHeeveyp+86=U_hGkfvGA@mail.gmail.com Whole thread Raw |
| In response to | Re: Pluggable toaster (Aleksander Alekseev <aleksander@timescale.com>) |
| Responses |
Re: Pluggable toaster
(Aleksander Alekseev <aleksander@timescale.com>)
|
| List | pgsql-hackers |
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@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
pgsql-hackers by date: