Hi Nikita, > Using Table AM Routine and routing AM methods calls via it is a topic for > further discussion, > if Pluggable TOAST will be committed. [...] And even then it would be an open > issue.
>From personal experience with the project I have serious doubts this is going to happen. Before such invasive changes are going to be accepted there should be a clear understanding of how exactly TOASTers are supposed to be used. This should be part of the documentation in the patchset. Additionally there should be an open-soruce or source-available extension that actually demonstrates the benefits of TOASTers with reproducible benchmarks (we didn't even get to that part yet). > TOAST implementation is not necessary for Table AM. What other use cases for TOAST do you have in mind? >> > 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. To clarify, the concern about "N TOASTers vs M TableAM" was expressed by Robert Haas back in Jan 2022: > I agree ... but I'm also worried about what happens when we have > multiple table AMs. One can imagine a new table AM that is > specifically optimized for TOAST which can be used with an existing > heap table. One can imagine a new table AM for the main table that > wants to use something different for TOAST. So, I don't think it's > right to imagine that the choice of TOASTer depends solely on the > column data type. I'm not really sure how this should work exactly ... > but it needs careful thought. This is the most important open question so far to my knowledge. It was never addressed, it doesn't seem like there is a plan of doing so, the suggested alternative approach was ignored, nor are there any strong arguments that would defend this design choice and/or criticize the alternative one (other than general words "don't worry we know what we are doing"). This what I mean by the community feedback being discarded. -- Best regards, Aleksander Alekseev
