diff --git a/content/zh/post/whx/openGauss1.md b/content/zh/post/whx/openGauss1.md
new file mode 100644
index 0000000000000000000000000000000000000000..02e7349878cab5e8a04cf15dd2463ebe91dec678
--- /dev/null
+++ b/content/zh/post/whx/openGauss1.md
@@ -0,0 +1,33 @@
++++
+title = "openGauss社区入门（openGauss高性能学习小结）"
+date = "2022-08-20"
+tags = ["openGauss社区开发入门"]
+archives = "2020-08"
+author = "whx"
+summary = "openGauss社区开发入门"
+img = ""
+times = "10:00"
++++
+## 1.1 CBO优化器
+openGauss优化器是基于代价的优化。在CBO优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。
+## 1.2 支持LLVM
+openGauss的LLVM（Low Level Virtual Machine）技术，提供了查询动态编译执行的能力。openGauss借助LLVM提供的库函数，依据查询执行计划树，将原本在执行器阶段才会确定查询实际执行路径的过程提前到执行初始化阶段，从而规避原本查询执行时候伴随的函数调用、逻辑条件分支判断以及大量的数据读取等问题，以达到提升查询性能的目的。
+## 1.3 向量化引擎
+openGauss提供向量化引擎，通常用在OLAP数据仓库类系统，因为分析型系统通常都是数据处理密集型负载，基本上都是采用顺序方式来访问表中大部分的数据，然后进行计算，最后将计算结果输出给终端用户。
+## 1.4 行列混合存储
+openGauss 支持行存储和列存储两种存储模型，用户可以根据应用场景，建表的时候选择行存储还是列存储表。一般情况下，如果表的字段比较多（大宽表），查询中涉及到的列不很多的情况下，适合列存储。如果表的字段个数比较少，查询大部分字段，那么选择行存储比较好。
+## 1.5 自适应压缩
+数据压缩是当前数据库采用的主要技术。数据类型不同，适用于它的压缩算法不同。对于相同类型的数据，其数据特征不同，采用不同的压缩算法达到的效果也不相同。自适应压缩正是从数据类型和数据特征出发，采用相应的压缩算法，实现了良好的压缩比、快速的入库性能以及良好的查询性能。
+## 1.6 SQL by pass
+在典型的OLTP场景中，简单查询占了很大一部分比例。这种查询的特征是只涉及单表和简单表达式的查询，因此为了加速这类查询，提出了SQL-BY-PASS框架，在parse层对这类查询做简单的模式判别后，进入到特殊的执行路径里，跳过经典的执行器执行框架，包括算子的初始化与执行、表达式与投影等经典框架，直接重写一套简洁的执行路径，并且直接调用存储接口，这样可以大大加速简单查询的执行速度。
+## 1.7 鲲鹏NUMA架构优化
+鲲鹏NUMA架构优化，主要面向鲲鹏处理器架构特点、ARMv8指令集等，进行相应的系统优化，涉及到操作系统、软件架构、锁并发、日志、原子操作、Cache访问等一系列的多层次优化，从而大幅提升了openGauss数据库在鲲鹏平台上的处理性能。
+## 1.8 支持线程池高并发
+线程池技术的整体设计思想是线程资源池化、并且在不同连接之间复用。系统在启动之后会根据当前核数或者用户配置启动固定一批数量的工作线程，一个工作线程会服务一到多个连接session，这样把session和thread进行了解耦。因为工作线程数是固定的，因此在高并发下不会导致线程的频繁切换，而由数据库层来进行session的调度管理。
+## 1.9 SMP并行执行
+openGauss的SMP并行技术是一种利用计算机多核CPU架构来实现多线程并行计算，以充分利用CPU资源来提高查询性能的技术。在复杂查询场景中，单个查询的执行较长，系统并发度低，通过SMP并行执行技术实现算子级的并行，能够有效减少查询执行时间，提升查询性能及资源利用率。SMP并行技术的整体实现思想是对于能够并行的查询算子，将数据分片，启动若干个工作线程分别计算，最后将结果汇总，返回前端。SMP并行执行增加数据交互算子（Stream），实现多个工作线程之间的数据交互，确保查询的正确性，完成整体的查询。
+## 1.10 Xlog no Lock Flush
+对WalInsertLock进行优化，利用LSN（Log Sequence Number）及LRC（Log RecordCount）记录了每个backend的拷贝进度，取消WalInsertLock机制。在backend将日志拷贝至WalBuffer时，不用对WalInsertLock进行争抢，可直接进行日志拷贝操作。并利用专用的WalWriter写日志线程，不需要backend线程自身来保证xlog的Flush。
+## 1.11 Parallel Page-based Redo For Ustore
+通过利用Prefix和suffix来减少update WAL log的写入，通过把回放线程分多个类型来解决Ustore DML WAL大多都是多页面回放问题；同时把Ustore的数据页面回放按照blkno去分发。
+