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
