研究生在读，因为目前的方向与openGauss和Postgres有关，所以大概在今年4月就开始接触了openGauss。
最初是尝试在docker里开始使用openGauss，从源码开始编译。记得当时编译好之后，发现少了很多工具，比如gs_om这些，作为一个开源项目，文档质量。后来在群里听说gs_om这些工具类似于对gs_ctl这些工具的封装。
初识MOT内存表开始看代码时，由于资料比较少，只能看些Postgres的源码解析，在那个时候，我并未发现openGauss有什么重大改动。所以对openGauss的印象没有特别高。直到后来在使用中，我看到了MOT内存表。这个新奇的引擎还有一篇学术论文发表。另外，上课的王鹏博士也是作者之一。
PG没有内存表引擎，就是一个很令人遗憾的事情，在一些追求高性能的场景，内存表引擎无疑是比较优的选择。MOT的论文也提出了五个关键需求：(1)无共享架构的事务扩展；(2)多socket多核服务器上的高扩展效率；(3)得益于大内存的性能，(4)高 SQL 覆盖率和操作性；(5)高可用性。基于这些需求，MOT选择了较为成熟的 Masstree 无锁实现并且对 Silo 进行了稳健的改进。只要稍微了解下MOT内存表的架构组成，就可以发现这是一个学术味道比较重的内存引擎。Masstree是基数树和B+树的结合而成的树,他结合了基数树和B+树的优点，这个数据结构在12年就被发表了出来。而Silo是一种新的内存数据库，在现代多核计算机上实现了很好的性能和可扩展性。Silo的设计初衷是为了高效地使用系统内存和缓存。Gauss团队把两个学术味道比较重的东西结合进了GaussDB和openGauss，并针对众核和华为泰山服务器做了优化，这是很先进的内存存储引擎。
在最开始使用MOT时，如果是从源码编译，则需要在configure时加上 --enable-mot ，否则无法使用。由于MOT是基于FDW（外部数据转换器）实现的，所以在使用上与openGauss的行存和列存还是有所区别的。比如使用控制表时的语句有所差别。
create FOREIGN table Mot_Table1 (id integer […]) [server mot_server];
drop FOREIGN table Mot_Table1;
此外，MOT还有一个值得关注的特性就是 JIT。相信在跑AP类的负载时，JIT的加入会有更好的性能表现。此外，我还比较关注MOT对于TPCH的表现，拭目以待！
