diff --git "a/content/zh/post/rentc/Linux-Centos6,7\347\275\221\347\273\234\351\205\215\347\275\256.md" "b/content/zh/post/rentc/Linux-Centos6,7\347\275\221\347\273\234\351\205\215\347\275\256.md"
deleted file mode 100644
index a273223a04c9874e31faabe87b6930eeef8f5474..0000000000000000000000000000000000000000
--- "a/content/zh/post/rentc/Linux-Centos6,7\347\275\221\347\273\234\351\205\215\347\275\256.md"
+++ /dev/null
@@ -1,22 +0,0 @@
-+++
-
-title = "Linux(Centos6,7)网络配置"
-
-date = "2022-09-09"
-
-tags = ["Linux(Centos6,7)网络配置"]
-
-archives = "2022-09"
-
-author = "海量数据"
-
-summary = "Linux(Centos6,7)网络配置"
-
-img = "/zh/post/Rentc/title/title.jpg"
-
-times = "18:30"
-
-+++
-
-背景：在安装数据库前很多很多人会选择安装一台虚拟机，安装虚拟机在非常重要的是配置网络，这里介绍两种配置网络的方法。
1.首先我们介绍一下一些常用的关于网络的linux命令 ，我们可以通过下面的命令来查看我们的网卡信息，选择我们需要配置的网卡。
ifconfig：查看活动的网卡信息，仅限于活动的网卡
ifconfig eth[0-9]：后面跟某个网卡则可以直接查看某个网卡的信息
ifconfig –a ：则是查看所有的网卡信息，包括活动或非活动的网卡信息
2.⑴、命令配置法：ifconfig和ip
Ifconfig ethx:x IP/netmask
ip addr add IP dev ethx label ethX:X
利用命令配置的只是暂时的IP地址，如果重启网络服务和系统都会失效的。
⑵、配置文件配置法：
修改/etc/sysconfig/network-scripts/ifcfg-ethx:x
DEVICE=ethx:x
BOOTPROTO=static
IPIPADDR= IP地址
NETMASK= 子网掩码
GATEWAY= 网关
ONBOOT=YES 是否开机启用
HWADDR=...... MAC
参考文档：[https://blog.51cto.com/chrinux/1188108](https://blog.51cto.com/chrinux/1188108)
-
diff --git "a/content/zh/post/rentc/SQL\345\274\225\346\223\216-\350\257\215\346\263\225\345\210\206\346\236\220.md" "b/content/zh/post/rentc/SQL\345\274\225\346\223\216-\350\257\215\346\263\225\345\210\206\346\236\220.md"
deleted file mode 100644
index 1f08935d7c1f2ff540623edc5f1fb38dbef56b0a..0000000000000000000000000000000000000000
--- "a/content/zh/post/rentc/SQL\345\274\225\346\223\216-\350\257\215\346\263\225\345\210\206\346\236\220.md"
+++ /dev/null
@@ -1,19 +0,0 @@
-+++
-
-title = "SQL引擎-词法分析"
-
-date = "2022-09-09"
-
-tags = ["SQL引擎-词法分析"]
-
-archives = "2022-09"
-
-author = "海量数据"
-
-summary = "SQL引擎-词法分析"
-
-img = "/zh/post/Rentc/title/title.jpg"
-
-times = "18:40"
-
-+++
前言：是数据库重要的子系统之一。SQL引擎负责对用户输入的SQL语言进行编译，生成可执行的执行计划，然后将执行计划交给执行引擎进行执行。
SQL引擎包括：
1.解析器，根据SQL语句生成一棵语法解析树（parse tree）。
2. 分析器 ， 对语法解析树进行语义分析 ，生成一 棵查询树（ query tree）。
3.重写器，按照规则系统中存在的规则对查询树进行改写。
4.计划器，基于查询树生成一棵执行效率最高的计划树（plan tree）。
5.执行器，按照计划树中的顺序访问表和索引，执行相应查询。
SQL解析对输入的SQL语句进行词法分析、语法分析、语义分析，获得查询解析树或者逻辑计划。这篇文章主要是介绍词法分析。
词法分析：从查询语句中识别出系统支持的关键字、标识符、操作符、终结符等，每个词确定自己固有的词性。
1.词法结构和语法结构分别由scan.l和gram.y文件定义，并通过lex和yacc分别编译成scan.cpp和gram.cpp文件。
2.raw_parser:Lex ( Lexical Analyzar) 词法分析工具,在文件 scan.l里定义。负责识别标识符，SQL 关键字等，对于发现的每个关键字或者标识符都会生成一个记号并且传递给分析器;Yacc (Yet Another Compiler Compiler) 语法分析器,在文件 gram.y里定义。包含一套语法规则和触发规则时执行的动作.
3.由lex工具进行词法分析。lex工具通过对已经定义好的词法文件进行编译，生成词法分析的代码。 词法文件是scan.l，它根据SQL语言标准对SQL语言中的关键字、标识符、操作符、常量、终结符进行了定义和识别
4.词法分析将一个SQL划分成多个不同的token，每个token会有自己的词性。由三部分组成，分别是名字、Token值、类别。名字是字符串原型，Token值是一个int型的数。kwlist.h中定义了大量的关键字
举例说明：
diff --git "a/content/zh/post/rentc/openGauss\346\237\245\350\257\242\344\274\230\345\214\226.md" "b/content/zh/post/rentc/openGauss\346\237\245\350\257\242\344\274\230\345\214\226.md"
index 0dc2dff21cf11d6e085b3fa18a7c4eeab60ffdee..1ce7be47ba801da137b048172401771d58c5c35c 100644
--- "a/content/zh/post/rentc/openGauss\346\237\245\350\257\242\344\274\230\345\214\226.md"
+++ "b/content/zh/post/rentc/openGauss\346\237\245\350\257\242\344\274\230\345\214\226.md"
@@ -18,4 +18,50 @@ times = "10:40"
+++
-优化器(optimizer)的任务是创建最佳执行计划。一个给定的SQL查询以及一个查询树实际上可以以多种不同的方式执行，每种方式都会产生相同的结果集。如果在计算上可行，则查询优化器将检查这些可能的执行计划中的每一个，最终选择预期运行速度最快的执行计划。
在某些情况下，检查执行查询的每种可能方式都会占用大量时间和内存空间,特别是在执行涉及大量连接操作（join）的查询时。为了在合理的时间内确定合理的（不一定是最佳的）查询计划，当查询连接数超过阈值时，openGauss使用遗传查询优化器(genetic query optimizer)，通过遗传算法来做执行计划的枚举。
优化器的查询计划（plan）搜索过程实际上与称为路径（path）的数据结构一起使用，该路径只是计划的简化表示，其中仅包含确定计划所需的关键信息。确定代价最低的路径后，将构建完整的计划树以传递给执行器。这足够详细地表示了所需的执行计划，供执行者运行。在本节的其余部分，将忽略路径和计划之间的区别。
**1） 生成查询计划**
首先，优化器会生成查询中使用的每个单独关系（表）的计划。候选计划由每个关系上的可用索引确定。对关系的顺序扫描是查询最基本的方法，因此总是会创建顺序扫描计划。假设在关系上定义了索引（例如B树索引），并且查询属性恰好与B树索引的键匹配，则使用B树索引创建另一个基于索引的查询计划。如果还存在其他索引并且查询中的限制恰好与索引的关键字匹配，则将考虑其他计划生成更多计划。
其次，如果查询需要连接两个或多个关系，则在找到所有可行的扫描单个关系的计划之后，将考虑连接关系的计划。连接关系有3种可用的连接策略：
**（1） 嵌套循环连接：对在左关系中找到的每一行，都会扫描一次右关系。此策略易于实施，但非常耗时。（但是如果可以使用索引扫描来扫描右关系，这可能是一个不错的策略。可以将左关系的当前行中的值用作右索引扫描的键。）**
**（2）合并连接：在开始连接之前，对进行连接的每个关系的连接属性进行排序。然后，并行扫描进行连接的这两个关系，并组合匹配的行以形成连接行。这种连接更具吸引力，因为每个关系只需扫描一次。所需的排序可以通过明确的排序步骤来实现，也可以通过使用连接键上的索引以正确的顺序扫描关系来实现。**
**（3） 哈希连接：首先将正确的关系扫描并使用其连接属性作为哈希键加载到哈希表（hash table，也叫散列表）中。接下来，扫描左关系，并将找到的每一行的适当值用作哈希键，以在表中找到匹配的行。**
当查询涉及两个以上的关系时，最终结果必须由构建连接树来确定。优化器检查不同的可能连接顺序以找到代价最低的连接顺序。
如果查询所使用的关系数目较少（少于启动启发式搜索阈值），那么将进行近乎穷举的搜索以找到最佳连接顺序。优化器优先考虑存在WHERE限定条件子句中的两个关系之间的连接（即存在诸如rel1.attr1 = rel2.attr2之类的限制），最后才考虑不具有join子句的连接对。优化器会对每个连接操作生成所有可能的执行计划，然后选择（估计）代价最低的那个。当连接表数目超过geqo_threshold时，所考虑的连接顺序由基因查询优化（Genetic Query Optimization，GEQO）启发式方法确定。
完成的计划树包括对基础关系的顺序或索引扫描，以及根据需要的嵌套循环、合并、哈希连接节点和其他辅助步骤，例如排序节点或聚合函数计算节点。这些计划节点类型中的大多数具有执行选择（丢弃不满足指定布尔条件的行）和投影（基于给定列值计算派生列集，即执行标量表达式的运算）的附加功能。优化器的职责之一是将WHERE子句中的选择条件附加起来，并将所需的输出表达式安排到计划树的最适当节点上。
**2） 查询计划代价估计**
openGauss的优化器是基于代价的优化器，对每条SQL语句生成的多个候选的计划，优化器会计算一个执行代价，最后选择代价最小的计划。
通过统计信息，代价估算系统就可以了解一个表有多少行数据、用了多少个数据页面、某个值出现的频率等，以确定约束条件过滤出的数据占总数据量的比例，即选择率。当一个约束条件确定了选择率之后，就可以确定每个计划路径所需要处理的行数，并根据行数可以推算出所需要处理的页面数。当计划路径处理页面的时候，会产生I/O代价。而当计划路径处理元组的时候（例如针对元组做表达式计算），会产生CPU代价。由于openGauss是单机数据库，无服务器节点间传输数据（元组）会产生通信的代价，因此一个计划的总体代价可以表示为：
总代价 = I/O代价 + CPU代价
openGauss把所有顺序扫描一个页面的代价定义为单位1，所有其他算子的代价都归一化到这个单位1上。比如把随机扫描一个页面的代价定义为4，即认为随机扫描一个页面所需代价是顺序扫描一个页面所需代价的4倍。又比如，把CPU处理一条元组的代价为0.01，即认为CPU处理一条元组所需代价为顺序扫描一个页面所需代价的1/100。
从另一个角度来看，openGauss将代价又分成了启动代价和执行代价，其中：
总代价 = 启动代价 + 执行代价
**（1） 启动代价。**
从SQL语句开始执行到此算子输出第一条元组为止，所需要的代价称为启动代价。有的算子启动代价很小，比如基表上的扫描算子，一旦开始读取数据页，就可以输出元组，因此启动代价为0。有的算子的启动代价相对较大，比如排序算子，它需要把所有下层算子的输出全部读取到，并且把这些元组排序之后，才能输出第一条元组，因此它的启动代价比较大。
**（2） 执行代价。**
从输出第一条算子开始，至查询结束，所需要的代价，称为执行代价。这个代价中又可以包含CPU代价、I/O代价，执行代价的大小与算子需要处理的数据量有关，也与每个算子完成的功能有关。处理的数据量越大、算子需要完成的任务越重，则执行代价越大。
参考文档：[https://www.modb.pro/db/208822](https://www.modb.pro/db/208822)
+优化器(optimizer)的任务是创建最佳执行计划。一个给定的SQL查询以及一个查询树实际上可以以多种不同的方式执行，每种方式都会产生相同的结果集。如果在计算上可行，则查询优化器将检查这些可能的执行计划中的每一个，最终选择预期运行速度最快的执行计划。
+
+在某些情况下，检查执行查询的每种可能方式都会占用大量时间和内存空间,特别是在执行涉及大量连接操作（join）的查询时。为了在合理的时间内确定合理的（不一定是最佳的）查询计划，当查询连接数超过阈值时，openGauss使用遗传查询优化器(genetic query optimizer)，通过遗传算法来做执行计划的枚举。
+
+优化器的查询计划（plan）搜索过程实际上与称为路径（path）的数据结构一起使用，该路径只是计划的简化表示，其中仅包含确定计划所需的关键信息。确定代价最低的路径后，将构建完整的计划树以传递给执行器。这足够详细地表示了所需的执行计划，供执行者运行。在本节的其余部分，将忽略路径和计划之间的区别。
+
+1） 生成查询计划
+
+首先，优化器会生成查询中使用的每个单独关系（表）的计划。候选计划由每个关系上的可用索引确定。对关系的顺序扫描是查询最基本的方法，因此总是会创建顺序扫描计划。假设在关系上定义了索引（例如B树索引），并且查询属性恰好与B树索引的键匹配，则使用B树索引创建另一个基于索引的查询计划。如果还存在其他索引并且查询中的限制恰好与索引的关键字匹配，则将考虑其他计划生成更多计划。
+
+其次，如果查询需要连接两个或多个关系，则在找到所有可行的扫描单个关系的计划之后，将考虑连接关系的计划。连接关系有3种可用的连接策略：
+
+（1） 嵌套循环连接：对在左关系中找到的每一行，都会扫描一次右关系。此策略易于实施，但非常耗时。（但是如果可以使用索引扫描来扫描右关系，这可能是一个不错的策略。可以将左关系的当前行中的值用作右索引扫描的键。）
+
+（2）合并连接：在开始连接之前，对进行连接的每个关系的连接属性进行排序。然后，并行扫描进行连接的这两个关系，并组合匹配的行以形成连接行。这种连接更具吸引力，因为每个关系需扫描一次。所需的排序可以通过明确的排序步骤来实现，也可以通过使用连接键上的索引以正确的顺序扫描关系来实现。
+
+（3） 哈希连接：首先将正确的关系扫描并使用其连接属性作为哈希键加载到哈希表（hash table，也叫散列表）中。接下来，扫描左关系，并将找到的每一行的适当值用作哈希键，以在表中找到匹配的行。
+
+当查询涉及两个以上的关系时，最终结果必须由构建连接树来确定。优化器检查不同的可能连接顺序以找到代价最低的连接顺序。
+
+如果查询所使用的关系数目较少（少于启动启发式搜索阈值），那么将进行近乎穷举的搜索以找到最佳连接顺序。优化器优先考虑存在WHERE限定条件子句中的两个关系之间的连接（即存在诸如rel1.attr1 = rel2.attr2之类的限制），最后才考虑不具有join子句的连接对。优化器会对每个连接操作生成所有可能的执行计划，然后选择（估计）代价最低的那个。当连接表数目超过geqo_threshold时，所考虑的连接顺序由基因查询优化（Genetic Query Optimization，GEQO）启发式方法确定。
+
+完成的计划树包括对基础关系的顺序或索引扫描，以及根据需要的嵌套循环、合并、哈希连接节点和其他辅助步骤，例如排序节点或聚合函数计算节点。这些计划节点类型中的大多数具有执行选择（丢弃不满足指定布尔条件的行）和投影（基于给定列值计算派生列集，即执行标量表达式的运算）的附加功能。优化器的职责之一是将WHERE子句中的选择条件附加起来，并将所需的输出表达式安排到计划树的最适当节点上。
+
+2） 查询计划代价估计
+
+openGauss的优化器是基于代价的优化器，对每条SQL语句生成的多个候选的计划，优化器会计算一个执行代价，最后选择代价最小的计划。
+
+通过统计信息，代价估算系统就可以了解一个表有多少行数据、用了多少个数据页面、某个值出现的频率等，以确定约束条件过滤出的数据占总数据量的比例，即选择率。当一个约束条件确定了选择率之后，就可以确定每个计划路径所需要处理的行数，并根据行数可以推算出所需要处理的页面数。当计划路径处理页面的时候，会产生I/O代价。而当计划路径处理元组的时候（例如针对元组做表达式计算），会产生CPU代价。由于openGauss是单机数据库，无服务器节点间传输数据（元组）会产生通信的代价，因此一个计划的总体代价可以表示为：
+
+总代价 = I/O代价 + CPU代价
+
+openGauss把所有顺序扫描一个页面的代价定义为单位1，所有其他算子的代价都归一化到这个单位1上。比如把随机扫描一个页面的代价定义为4，即认为随机扫描一个页面所需代价是顺序扫描一个页面所需代价的4倍。又比如，把CPU处理一条元组的代价为0.01，即认为CPU处理一条元组所需代价为顺序扫描一个页面所需代价的1/100。
+
+从另一个角度来看，openGauss将代价又分成了启动代价和执行代价，其中：
+
+总代价 = 启动代价 + 执行代价
+
+（1） 启动代价。
+
+从SQL语句开始执行到此算子输出第一条元组为止，所需要的代价称为启动代价。有的算子启动代价很小，比如基表上的扫描算子，一旦开始读取数据页，就可以输出元组，因此启动代价为0。有的算子的启动代价相对较大，比如排序算子，它需要把所有下层算子的输出全部读取到，并且把这些元组排序之后，才能输出第一条元组，因此它的启动代价比较大。
+
+（2） 执行代价。
+
+从输出第一条算子开始，至查询结束，所需要的代价，称为执行代价。这个代价中又可以包含CPU代价、I/O代价，执行代价的大小与算子需要处理的数据量有关，也与每个算子完成的功能有关。处理的数据量越大、算子需要完成的任务越重，则执行代价越大。
+
+参考文档：[https://www.modb.pro/db/208822](https://www.modb.pro/db/208822)
diff --git "a/content/zh/post/rentc/user\343\200\201role\345\214\272\345\210\253\344\270\216\344\275\277\347\224\250\346\235\203\351\231\220.md" "b/content/zh/post/rentc/user\343\200\201role\345\214\272\345\210\253\344\270\216\344\275\277\347\224\250\346\235\203\351\231\220.md"
deleted file mode 100644
index e3eb60766e77f9dce60d9decaef184acd1f65f37..0000000000000000000000000000000000000000
--- "a/content/zh/post/rentc/user\343\200\201role\345\214\272\345\210\253\344\270\216\344\275\277\347\224\250\346\235\203\351\231\220.md"
+++ /dev/null
@@ -1,23 +0,0 @@
-+++
-
-title = "user/role 区别与使用权限"
-
-date = "2022-09-30"
-
-tags = ["user/role 区别与使用权限"]
-
-archives = "2022-09-30"
-
-author = "Rentc"
-
-summary = "user/role 区别与使用权限"
-
-img = "/zh/post/Rentc/title/title.jpg"
-
-times = "10:40"
-
-+++
-
-定义
角色是拥有数据库对象和权限的实体。在不同的环境中角色可以认为是一个用户，一个组或者兼顾两者。
从创建用户和角色的语义（create user/role）上看也没有区别，唯一的区别就是用户默认带有login权限。
查询用户相关信息可以查看视图pg_user，查看角色相关信息可以查看pg_roles，但如果你查看pg_user和pg_roles的视图定义，会发现这两个视图都来源于基表pg_authid。
**所以我们可以理解用户就是带有login属性的角色。**
-#### 私有用户
-角色的属性有很多，可以通过\h create user/role来查看，也可以直接在pg_authid系统表中查看。
这里主要介绍一个比较重要的属性：**INDEPENDENT**，即在非三权分立模式下，创建具有INDEPENDENT属性的私有用户，
针对该私有用户的对象，系统管理员和拥有CREATEROLE属性的安全管理员在未经其授权前，只能进行控制操作（DROP、ALTER、TRUNCATE），无权进行INSERT、DELETE、SELECT、UPDATE、COPY、GRANT、REVOKE、ALTER OWNER操作。