Hi Nikita, > Pluggable TOAST API was designed with storage flexibility in mind, and Custom > TOAST mechanics is > free to use any storage methods
Don't you think that this is an arguable design decision? Basically all we know about the underlying TableAM is that it stores tuples _somehow_ and that tuples have TIDs [1]. That's it. We don't know if it even has any sort of pages, whether they are fixed in size or not, whether it uses shared buffers, etc. It may not even require TOAST. (Not to mention the fact that when you have N TOAST implementations and M TableAM implementations now you have to run N x M compatibility tests. And this doesn't account for different versions of Ns and Ms, different platforms and different versions of PostgreSQL.) I believe the proposed approach is architecturally broken from the beginning. It looks like the idea should be actually turned inside out. I.e. what would be nice to have is some sort of _framework_ that helps TableAM authors to implement TOAST (alternatively, the rest of the TableAM except for TOAST) if the TableAM is similar to the default one. In other words the idea is not to implement alternative TOASTers that will work with all possible TableAMs but rather to simplify the task of implementing an alternative TableAM which is similar to the default one except for TOAST. These TableAMs should reuse as much common code as possible except for the parts where they differ. Does it make sense? Sorry, I realize this will probably imply a complete rewrite of the patch. This is the reason why one should start proposing changes from gathering the requirements, writing an RFC and run it through several rounds of discussion. [1]: https://www.postgresql.org/docs/current/tableam.html -- Best regards, Aleksander Alekseev