Hi Nikita, > >I don't argue with most of what you say. I am just pointing out the > >reason why the chosen approach "N TOASTers x M TableAMs" will not > >work: > > We assume that TAM used in custom Toaster works as it is should work, > and leave TAM internals to this TAM developer - say, we do not want to > change internals of Heap AM. > > We don't want to create some kind of silver bullet.
This is exactly the point. In order to not to create a silver bullet, TOASTers should be limited to a single TableAM. The one we know uses pages of a known fixed size, the one that actually requires TOAST because pages are relatively small, etc. > That's what the TOAST API is - just an interface that all custom > TOAST implementations use to have a common entry point from any TAM, > [...] I believe this is the source of misunderstanding. Note that not _any_ TableAM needs TOAST to begin with. As an example, if one chooses to implement a column-organized TableAM that stores all text/bytea attributes in a separate dictionary file this person doesn't need TOAST and doesn't want to be constrained by the need of choosing one. For this reason the "N TOASTers x M TableAMs" approach is architecturally broken. > keep in mind that different kinds of data require very > different approach to external storage - say, JSON TOAST works with > maps of keys and values, [...] To clarify: is an ability to specify TOASTers for given columns and/or types also part of the plan? > 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. -- Best regards, Aleksander Alekseev