ITPub博客

DB4AI这个方向中，数据库通过集成AI能力，在用户进行AI计算时就可以避免数据搬运的问题。不同于其他的DB4AI框架，本次openGauss开源的原生框架是通过添加AI算子的方式完成数据库中的AI计算。

pg_chameleon是一个用Python 3编写的实时复制工具，经过内部适配，目前支持MySQL迁移到openGauss。

pgloader是一个数据导入工具，使用COPY命令将数据导入到PostgreSQL。pgloader有两种工作模式，一种是从文件导入，一种是迁移数据库。pgloader在两种情况下都使用PostgreSQL的COPY协议高效的传输数据。

使用 HeidiSQL 连接 openGauss 服务

本文档主要对Postgresql插件移植到openGauss的过程提供指导说明，旨在让开发人员对PG插件所需要的修改有一个具体的了解，基于该文档，可基本实现PG插件移植到openGauss。

Ora2Pg是一个将Oracle迁移至PostgreSQL的开源工具，通过连接Oracle数据库，自动扫描并提取其中的对象结构及数据，产生SQL脚本，通过手动或自动的方式将其应用到PostgreSQL。

视图与基本表不同，是一个虚拟的表。数据库中仅存放视图的定义，而不存放视图对应的数据，这些数据仍存放在原来的基本表中。若基本表中的数据发生变化，从视图中查询出的数据也随之改变。从这个意义上讲，视图就像一个窗口，透过它可以看到数据库中用户感兴趣的数据及变化。

除了DML之外的所有查询都通过ProcessUtility模块来执行，包括了各类DDL语句、事务相关语句、游标相关语句等。上层调用函数为exec_simple_query函数，其中PortalStart函数和PortalDrop函数部分较为简单。核心函数是PortalRun函数下层调用的standard_ProcessUtility函数，该函数通过switch case语句处理了各种类型的查询语句，包括事务相关查询、游标相关查询、schema相关操作、表空间相关操作、表定义相关操作等。

执行引擎位于优化器和存储引擎之间，负责将数据从存储引擎读取出来，根据计划将数据处理加工返回给客户端。

执行引擎一般负责查询的执行，执行引擎在SQL执行栈中起到接收优化器生成的执行计划Plan、并对通过存储引擎提供的数据读写接口，实现对数据进行计算得到查询的结果集。在典型的OLTP场景中，简单查询占了很大一部分比例。这种查询的特征是只涉及单表和简单表达式的查询，因此为了加速这类查询，openGauss提出了SQL by pass框架，在parse层对这类查询做简单的模式判别后，进入到特殊的执行路径里

介绍执行计划的处理过程。

SQL引擎执行查询主要经历了词法语法解析、查询重写、查询规划和计划执行等步骤。其中，在查询规划过程中，为了生成可执行的最优计划，首先要生成路径，而由于路径存在多样性，因此需要对路径进行淘汰选择。目前优化器进行路径的选择主要是基于估算的代价。在代价估算时，需要使用基表或连接表的行数，而在很多时候，优化器无法获得准确的行数值，因此需要对行数进行估算（Cardinality Estimation），然后再计算代价。

查询重写SQL语言是丰富多样的，非常的灵活，不同的开发人员依据经验的不同，手写的SQL语句也是各式各样，另外还可以通过工具自动生成。SQL语言是一种描述性语言，数据库的使用者只是描述了想要的结果，而不关心数据的具体获取方式，输入数据库的SQL语言很难做到是以最优形式表示的，往往隐含了一些冗余信息，这些信息可以被挖掘用来生成更加高效的SQL语句。查询重写就是把用户输入的SQL语句转换为更高效的等价S

简单查询语句在业务处理线程Postgres上的执行流程，并介绍如何利用gdb梳理代码逻辑。

多线程架构启动过程详解