Hi, > > I think a test module for a table AM will really help developers. Just > > to add to the above list - how about the table AM implementing a > > simple in-memory (columnar if possible) database storing tables > > in-memory and subsequently providing readers with the access to the > > tables? > > That's a good idea.
Personally I would be careful with this idea. Practice shows that when you show the first incomplete, limited and buggy PoC it ends up being in the production environment the next day :) In other words sooner or later there will be users demanding a full in-memory columnar storage support from Postgres. I believe it would be a problem. Last time I checked TAM was not extremely good for implementing proper columnar storages, and there are lots of open questions when it comes to in-memory tables (e.g. what to do with foreign keys, inherited tables, etc). All in all I don't think we should provide something that can look / be interpreted as first-class alternative storage but in fact is not. > How about adding the same kind of coverage as dummy_index_am with a > couple of reloptions then? That can serve as a point of reference > when a table AM needs a few custom options. A second idea would be to > show how to use toast relations when implementing your new AM, where a > toast table could be created even in cases where we did not want one > with heap, when it comes to size limitations with char and/or varchar, > and that makes for a simpler needs_toast_table callback. Good ideas. Additionally we could provide a proxy TAM for a heap TAM which does nothing but logging used TAM methods, its arguments and return values. This would be a good example and also potentially can be used as a debugging tool. -- Best regards, Aleksander Alekseev