开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5） 新人直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
这题目让我想起非诚勿扰电影里面的台词，有意思吗？有意思呀！PostgreSQL 有意思，PolarDB for PostgreSQL 有意思。
大部分在PolarDB for MySQL 有的特性在 PolarDB for PostgreSQL 都可以使用。同时PolarDB for PostgreSQL 有一个开源的版本，也就是线下可以部署，这在整体的生态上是完整的，基于一些金融机构有线上和线下部署的数据同步的需求，那么这样的整体的解决方案对于一些机构来说是完整的，可控的。
从上图可以看到PolarDB for PostgreSQL 的部分在数据同步中，使用了方式是通过内存进行数据同步的方式，通过wal meta queue 从日志中同步化基础数据到Polardb 的从节点。并且将这些信息直接同步到从节点的shared buffer pool 中，同时下面也会将日志同步刷新到磁盘上，如polardb for mysql 一样通过REDO 的日志来进行数据的刷新，通过wal的数据进行从节点的内存的数据的冲刷。
这里注意实线和虚线，数据同步的同步和异步的数据同步的方式。基于这样的形式的数据的，主从节点数据的节点之间的延迟，我们是期待的，理论上比POSTGRESQL RDS 的 主从数据同步应该是要好的多，这样的方式在 POLARDB FOR MYSQL 上是有验证的，延迟有没有，有但是基本上在20ms 内，甚至更低。
所以如果Polardb for PostgreSQL的主从节点之间的数据差异在20ms内，对于读写分离来说，将不需要业务在去考虑这方面的基础架构的设计。
除此之外，我们对于下面的一些特性更加的有兴趣
1 数据冷热分离，在数据库层面上进行自动分层的技术，在数据存储中，最大的成本来源和可以进行削减的成本，大多来自于存储，类似我们这样的企业，数据一定有冷数据库，将几个T的冷数据如果能通过分层技术，下探到 OSS上，那么存储成本会几何级的下降。但具体的实施和方案，还需要更多的了解。因为这样的冷热分离是从物理上操作，而非业务逻辑上的冷热分离。
2 节点的增加和替换
这点也是我们对于现有的PostgreSQL 有想法的地方，当然可以增加pgbouncer，但是如果有一个能进行读写分离的插件的代理，那么将是我们最高兴 PostgreSQL 具有的功能，这样花一个POSTGRESQL 的钱得到两个节点，和读写分离的代理，最大化一些只读SQL 的自动和主节点的隔离，省时省力。
对于添加只读节点方面我们在POALRDB FOR MYSQL 也有深刻的体会，快速添加节点，如果是 几个T的从库添加那你就等着吧，但基于POALRDB 的 shared storage 和 内存同步数据的方案，几个T的从节点的添加也是在分钟级别可以获得这个能力，这对于突发的事件，要增加只读节点也是一个得心应手得事情。
3 内存全局话的设计
这点在POSTGRESQL 里面你需要使用到 POSTGRESQL 16 可以应用此功能，在POLARDB FOR POSTGRESQL 里面，PG14 就已经有了全局内存管理信息的功能，也就是不在有一个collector 来不断的收集各个客户进程里面的变动的数据信息，而是将这些放到整体的内存中来进行管理，对于节省内存来说有好处。
除此之外，还有ePQ 功能，我们希望能通过ePQ功能，让在原有的CPU 数量上，提升性能 50%，当然这些都需要进行测试和验证。
最后，在相关人员的介绍中，相关的硬件中，以及包含了硬件压缩的芯片，可以在数据存储在磁盘时进行硬件压缩和解压缩，预计可以提高数据存储 30%的平均容量。
所以写到这里，我有点期待后续，如果一个PG，更快，更便宜，更能在低版本使用高版本的一些特性和功能，那倒是有点意思。
