要理解或描述数据同步的过程机制，需要首先要了解GaussDB(DWS)的DN高可用架构，理解涉及数据同步的各组件的关系、数据类型、数据流向、设计原理和目的。GaussDB(DWS)的DN高可用架构为主、备、从备架构。即在分布式环境中，完整的集群数据采用分片技术分布在多个DN组上，每组DN承担一个数据分片，包括：一个主DN、一个备DN和一个从备DN。主和备各有一份完整的数据，从备上一般不存储数据，仅在备机故障时做数据的暂存。主、备、从备高可用架构下，主、备及主、从备之间均会建立流复制通道。流复制又分为日志复制和数据页复制。日志复制用于同步主DN由于WAL机制刷到磁盘上的XLOG，同步到备DN进行回放。数据页复制用于同步批量导入的行存数据、或列存CU文件。需要注意的一点是，从备仅用于存放XLOG和数据，回放（replay）仅发生在备DN上。

NBU侵入式部署调优Maximum jobs per client：此值设定每个NBU client发送的并行处理任务数，通常Roach与并行参数相对性，一般设置为DN数+CN数为最佳。NBU非侵入式部署调优Maximum jobs per client：此值设定每个NBU client发送的并行处理任务数，通常Roach与并行参数相对性，一般设置为：(DN数+CN数)*（Roach client 服务的Roach agent）个数为最佳。超时设置：超时属性适用于选定的Master server、Media Server以及NBU client。Client connect timeout：此选项指定服务器连接客户端时等待的秒数。默认值为300s。一般Roach备份业务中，建议此值设置为3600s或者更高。此选项适用于NBU Master Server、NBU Media Server、NBU Client。Client read timeout：此选项指定用于客户端读取超时的秒数。此选项适用于NBU Master Server、NBU Media Server。默认值为300s，如果服务器在客户端在此超时时间内没有从客户端得到响应，则备份/恢复任务失败，报错误码13。特别是针对于NBU Job复用场景，文件间隔传输时间超过此值，则备份/恢复任务失败。建议此值设置为3600s或者更高。Media server connect timeout：此选项用于指定Master Server连接Media Server的等待超时描述，默认值为300s。建议此值设置为3600s。此选项适用于NBU Master Server、NBU Media Server。

Roach工具目前支持两种NBU部署结构，分别为NBU侵入式部署与NBU非侵入式部署，两种部署方式的参数调优分别如下：1、通用参数调优Maximum concurrent jobs此值指定了对应存储单元上最大作业数量，取值范围为1-256。例如准备将三个备份作业发送到存储单元，并将“最大并发作业数”设置为两个。前两个作业开始，而第三个作业等待。Maximum vault jobs：此属性指定在master server上允许活动的最大活跃job数量。如果达到了允许活动的job限制，则将后续的kob排队，并且它们状态在“活动监视器”中显示为“已排队”。此属性设置范围为1~200， 当备份过程并发job数大大超过200，则master server会出现瓶颈，造成任务排队耗时。此时应考虑部署多Master Server模式。设置NET_BUFFER_SZ ：在应用Netbackup备份数据到带库时，有一个NET_BUFFER_SZ参数，决定media server与client之间数据传输的缓冲池大小，该参数值默认为32032 bytes，以文件形式保存于%Install_Path/netbackup/目录下。通常默认值都较小，如果希望修改该参数值，则直接修改%Install_Path/netbackup/NET_BUFFER_SZ即可。设置一个足够大的NET_BUFFER_SZ某些情况下能够有效提高备份的速度，推荐在server/client端都设置该参数。

NBU软件提供的libxbsa64.so动态库（实现了标准的XBSA系列接口），将本地数据传送到NBU服务器，然后由NBU服务器负责落盘到磁带介质上。GaussDB的专用备份工具Roach，负责调用libxbsa64.so库将本地数据库文件备份到远端NBU服务器。本章节则主要针对开发者，介绍XBSA系列接口。备份相关接口备份过程中涉及的XBSA相关接口主要如下：BSAQueryApiVersion：该接口用于确定Netbackup XBSA接口的当前版本。BSAInit：该接口用于对XBSA应用程序进行身份验证，与NetBackup XBSA接口建立session会话，并为调用者的后续API调用建立环境。注意，BSAInit不支持嵌套创建session会话。BSABeginTxn：该接口用于创建一个事物，这里的事物和数据库事物概念相似，BSABeginTxn（）调用向NetBackup XBSA接口指示作为原子单位执行的一个或多个操作的开始，即所有操作将成功或没有成功。可以将一个动作假定为为特定目的而进行的单个函数调用或一系列函数调用。例如，一个BSACreateObject（）调用后跟多个BSASendData（）调用并以BSAEndData（）调用终止可以被视为单个操作。在正常使用中，BSABeginTxn（）调用总是与随后的BSAEndTxn（）调用耦合。如果在事务期间调用BSATerminate（），则事务中止。【注意】BSABeginTxn不支持嵌套创建事物。BSACreateObject：BSACreateObject调用在NetBackup中创建一个XBSA对象。该调用将启动NetBackup XBSA接口与NetBackup服务器之间的通信。然后可以将XBSA对象数据传递到内存缓冲区中。BSACreateObject调用中的dataBlockPtr参数允许调用者获取有关NetBackup XBSA接口所需的缓冲区结构的信息。BSASendData：BSASendData（）将字节数据流发送到缓冲区中的NetBackup XBSA接口。如果要发送的字节数据流很大，则可以多次调用BSASendData（）。此调用只能在BSACreateObject（）或另一个BSASendData（）调用之后使用。BSAEndData：调用方在调用BSACreateObject之后调用零次或多次BSASendData，当前备份文件传输完毕后调用BSAEndData，用于通知Netbackup服务器当前文件传输结束BSAEndTxn：BSAEndTxn与BSABeginTxn耦合使用，以标识将被视为事务的API调用或一组API调用。BSATerminate：BSATerminate调用终止与NetBackup XBSA接口的会话，该接口由BSAInit调用对应，释放当前session会话获取的所有资源。如果在事务内调用BSATerminate（），则事务中止。

备份数据流NBU 一般涉及NBU Master Server、NBU Media Server、NBU client，属于一个three-trie结构。主要介绍NBU进程工作原理，方便使用者、开发者了解NBU备份流程，排查问题。下图中为通过备份所涉及的数据流向：基本备份过程：1、启动备份方式当 nbpem 服务检测到某项作业到了启动时间时，将开始进行预定的备份操作。nbpem会检查到了启动时间的预定客户机备份的策略配置。如果管理员在 NetBackup 管理控制台中选择了手动备份选项，将开始进行即时手动备份。这会使 bprd 联系 nbpem，然后 nbpem 将处理管理员所选择的策略、客户机和日程表。当客户机上的用户通过该客户机上的用户界面（或者通过 bpbackup 或xbsa系列接口）启动备份或回复时，将开始进行用户控制的备份或回复操作。这将调用该客户机的 XBSA程序，该程序向主服务器上的请求后台驻留程序 bprd发送请求。当前Roach NBU介质备份采用这种启动方式。2、接收备份任务：响应进程（bprd）接收到客户端的备份请求bprd：request manager请求管理器:bprd是Master Server的守护进程，bprd进程主要负责对客户机请求作出响应，并将并向nbjm发出 job请求，用于提交备份并获取job ID。3、将请求转发个策略执行管理器nbpmnbpem：policy execution manager策略执行管理器策略执行管理器服务 (nbpem) 执行以下操作：a. 通过nbproxy从 bpdbm 中获取策略列表, 查询到有效的备份policy的是否存在；   b. 向 nbjm 提交当前已到预定启动时间的所有作业(按照schedule执行时间的策略)。4、为备份job分配资源nbjm(job manager作业管理器)接收到任务后，nbjm首先会与bpjobd通信，将此job添加至job列表中，此时在Activity Monitor中该job以queue状态可见。b、nbjm通过nbrb 请求资源，nbrb负责分配资源以响应来自 nbjm 的请求。并从 nbemm （企业介质管理器服务）获取物理资源，并管理逻辑资源，如多路复用组、每个客户机的最多作业数、每个策略的最多作业数。当nbrb进程从nbemm获取到所需资源时，会返回通知nbjm资源已分配。当nbrm资源分配完成后，nbjm会调用 image database 创建临时快照文件，此时该job会在Activity Monitor中该job以active状态可见。5、开始备份当job处于active状态后，nbjm通过bpcompatd与NBU Media Server上的客户端服务（bpcd）进行连接，其中bpcompatd服务通过专用小交换机（PBX）和NetBackup旧式网络服务（vnetd）创建连接。b、bpcd进程是NBU Media Server上的守护进程，允许Master Server或NBU Client启动程序。bpcd接收到连接后会启动Netbackup 备份恢复管理器（bpbrm)。bpbrm进程服务通过PBX与vnetd与NBU client机器上的bpcd进程建立连接，启动NBU client机器上的bpbkar，其中bpbkar负责生成备份image，并将image数据发送至NBU Media Server上的bpdrm，对于每个备份或恢复job，都会在NBU Media Server上启动一个bpbrm实例用于传输image数据。bpdrm进程会启动磁带/磁盘管理进程bptm，对于磁盘介质，bptm直接与磁盘通信。对于磁带介质，bptm保留驱动器并向逻辑磁带接口守护程序（ltid）发出安装请求。ltid服务调用机械手驱动器守护程序（txxd，其中xx根据所使用的机械手的类型而异）。txxd守护程序将安装请求传达给机械手控制守护程序（txxcd），后者将安装介质。6、结束备份bpbkar服务通过bptm发送备份数据，以将其写入介质存储或磁盘存储。备份完成后，将通知nbjm并将消息发送到bpjobd。此时job在“Activity Monitor”中显示为“done”。nbjm服务还会将作业退出状态报告给nbpem，nbpem将重新计算作业的下一个到期时间。

当前GaussDB NBU备份方案支持两种部署架构，分别为侵入式部署与非侵入式部署。NBU侵入式部署当GaussDB所在集群支持NBU系列软件安装时，部署方式采用NBU侵入式部署，部署结构如下图：具体使用方法如下：【注意】：--media-destination：该参数为NBU policy名称--metadata-destination：元数据目录（本地路径）--prior-backup-key：该参数为增量备份依赖的备份集--backup-key：该参数指定恢复备份集NBU非侵入式部署当前NBU系列软件只支持x86机器，NBU非侵入式部署则支撑NBU系列软件无法在ARM、欧拉系统安装的场景。如下图所示，假如已有3节点GaussDB集群，Roach备份工具将本节点的集群数据通过TCP发送到远端NBU Media Server机器。每台NBU Media Server上面同时安装NBU Client，并部署Roach client组件，后者接收集群内Roach进程发来的备份数据，不落盘方式通过XBSA接口转发给本机的NBU Client，完成NBU备份。恢复流程也类似，只是数据流相反。备份方式：【注意】--media-destination：该参数为NBU policy名称。--metadata-destination：元数据目录（本地路径）。--nbu-on-remote：该参数指定部署方式为NBU非侵入式部署。--nbu-media-list：该参数指定NBU Media Server的ip清单，按行输入ip地址。--client-port：该参数指定Roach client插件的对外开放通信端口。--prior-backup-key：该参数为增量备份依赖的备份集。--backup-key：该参数指定恢复备份集。

随着技术的演进，数据也发生了巨大的变化，数据规模越来愈大、数据种类呈现多样性，数据处理的时效性要求也越来越高，GaussDB(DWS)实时数仓当前面临着巨大的机遇，也面临着巨大的挑战。同样的，强大工具来帮助我们定位各种各样的问题。数据库目录下有多种二进制文件，比如系统表、普通表、索引和日志文件等等，但是数据库运行过程中的问题，我们该如何利用这些文件去定位和分析问题呢？pagehack和pg_xlogdump就是我们解决问题的利器，帮助我们在故障定位中，解析各种文件的页面头和xlog日志。（1）数据库中的系统表有很多，但是在数据库data目录下，该如何把系统表和磁盘上的文件一一对应呢，我们可以通过pagehack查询data目录下的pg_filenode.map执行pagehack -f pg_filenode.map -t filenode_map，我们就可以看到如下结果，这里的relfilenode就对应磁盘上的文件。（2）除了系统表，另外一个常用的数据类型就是行存表的文件，通常对于存储异常、读取异常等问题，我们都需要通过pagehack查询行存表的头文件信息。首先连接DN上，查询到该行存表对应的relfilenode(16502)，到对应DN的data目录下，执行：pagehack -f 16502 -t heap。pd_lsn：本页面最后一次变更所写入的xlog记录对应的lsn。pd_special：用在索引页中，在索引页中它指向特殊空间的起始位置，在堆表页面中它指向页尾。pd_pagesize_version：页面大小以及页面布局的版本号。t_xmin: 保存插入该元组的事务的txid（事务号）t_xmax：保存删除或更新此元组的事务的txid。如果尚未删除或更新此元组，则t_xmax设置为0，即无效。t_infomask：用于标识元组当前的状态。t_infomask2：HOT链更新状态和当tuple的属性个数。

Stream算子是GaussDB分布式执行的关键算子之一，主要起到网络传输的作用，Stream算子由参数enable_stream_operator控制，如果关掉Stream算子，则可能导致生成不下推的计划。因为lineitem表关联的键l_partkey不是lineitem的分布键，需要添加Stream算子，但Stream功能被禁，于是只能生成不下推计划。GaussDB计划中常见的主要Stream算子包括Redistribute、Broadcast和Gather。Gather一般是分布式计划中，CN用于收集DN的数据进行最后的处理，除非最后收集的行数非常多，这个算子涉及性能问题一般较少。Redistribute和Broadcast一是对“互补”的算子，前者用于重分布，后者用于广播，生成计划时，优化器会根据代价大小来选择。当Join Key没有包含表的分布键的时候，一般会添加Redistribute路径，能选择Redistribute路径理论上也可选择Broadcast路径，最终选择哪条路径要看优化器估算的代价是多少。这两个算子可以通过参数enable_redistribute和enable_broadcast进行控制。在SMP开启的情况下，当并行度（dop）大于1时，一般还会有Local Redistribute、Split Redistribute、Local Broadcast和Split Broadcast；当倾斜优化开启时，还有PART REDISTRIBUTE PART ROUNDROBIN、PART_REDISTRIBUTE_PART_BROADCAST、PART_REDISTERIBUTE_PART_LOCAL等等，这些也是Stream算子，主要就是重分布、广播、RoundRobin的一些扩展形式。对于Stream方式的控制，一般的调优方式有Plan Hint、GUC参数、改善统计信息或估算信息。

如题，GaussDB中创建了一张表，想要用一个列保存数据的创建及更新时间，类似mysql、pg 的 on update  语法，Gauss中不支持，GaussDB应怎么设置？

  在SQL语句复杂、处理数据量大的AP场景下，单个查询对内存的需求越来越大，多个语句的并发很容易将系统的内存吃满，造成内存不足的问题。为了应对这种问题，GaussDB(DWS)引入了内存自适应控制的技术，在上述场景下能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。如何通过SQL进行分布式死锁的检测https://bbs.huaweicloud.com/forum/thread-02127157008986147021-1-1.html分布式死锁的检测与消除https://bbs.huaweicloud.com/forum/thread-0286157009096057018-1-1.html全文检索特性初探https://bbs.huaweicloud.com/forum/thread-0286157009369006019-1-1.htmlGaussDB(DWS)负载均衡的思考https://bbs.huaweicloud.com/forum/thread-02127157009588029025-1-1.htmlkeepAlived的学习https://bbs.huaweicloud.com/forum/thread-02113157009729783023-1-1.htmlGaussDB网络重传/丢包问题定位总结https://bbs.huaweicloud.com/forum/thread-0207157009857011029-1-1.html默认权限实现共享schemahttps://bbs.huaweicloud.com/forum/thread-0286157009975031020-1-1.htmlGaussDB(DWS)内存自适应控制技术解密https://bbs.huaweicloud.com/forum/thread-02127157010173033026-1-1.htmlGaussDB(DWS)的静态内存管理https://bbs.huaweicloud.com/forum/thread-02127157010223024027-1-1.htmlSQL引擎实现了内存自适应控制技术https://bbs.huaweicloud.com/forum/thread-0286157010288657021-1-1.htmlGaussDB(DWS)内存自适应的使用和参数控制https://bbs.huaweicloud.com/forum/thread-02127157010330009028-1-1.htmlC编写自定义函数https://bbs.huaweicloud.com/forum/thread-02127157010541344027-1-1.html路径干预https://bbs.huaweicloud.com/forum/thread-0220157010673029028-1-1.htmlScan方式的选择https://bbs.huaweicloud.com/forum/thread-02119157010771020026-1-1.html关联方式的选择https://bbs.huaweicloud.com/forum/thread-0286157010841138022-1-1.html

GaussDB优化器中表关联的主要方式有：Nest Loop，Hash Join和Merge Join，分别可以通过enable_nestloop、enable_hashjoin、enable_mergejoin进行控制，这种控制也不是绝对的，可以理解为是否优先选择。大部分场景下，三种路径的代价关系：Hash Join < Merge Join < Nest Loop。如果再把Merge Join路径关掉，可能就会选择Nest Loop路径。关联方式的控制开关一般用于调优或规避问题，但具体是否能够起作用要看具体的语句，除了当前关联方式，还有没有其他方式。实际场景中，一个语句中关联的算子较多，一般很难用参数enable_hashjoin或enable_nestloop或enable_mergejoin来控制某两个表的Join方式。Stream算子是GaussDB分布式执行的关键算子之一，主要起到网络传输的作用。GaussDB计划中常见的主要Stream算子包括Redistribute、Broadcast和Gather。Gather一般是分布式计划中，CN用于收集DN的数据进行最后的处理，除非最后收集的行数非常多，这个算子涉及性能问题一般较少。Redistribute和Broadcast一是对“互补”的算子，前者用于重分布，后者用于广播，生成计划时，优化器会根据代价大小来选择。当Join Key没有包含表的分布键的时候，一般会添加Redistribute路径，能选择Redistribute路径理论上也可选择Broadcast路径，最终选择哪条路径要看优化器估算的代价是多少。这两个算子可以通过参数enable_redistribute和enable_broadcast进行控制。在SMP开启的情况下，当并行度（dop）大于1时，一般还会有Local Redistribute、Split Redistribute、Local Broadcast和Split Broadcast；当倾斜优化开启时，还有PART REDISTRIBUTE PART ROUNDROBIN、PART_REDISTRIBUTE_PART_BROADCAST、PART_REDISTERIBUTE_PART_LOCAL等等。对于Stream方式的控制，一般的调优方式有Plan Hint、GUC参数、改善统计信息或估算信息。

GaussDB中扫描方式主要分顺序扫描和索引扫描，每种扫描方式都对应若干扫描算子，顺序扫描在行列存中对应的扫描算子分别是Seq Scan和CStore Scan算子（下面我们讨论中不加区分）。这些扫描算子大部分都可以通过开关来进行调控，例如Seq Scan，如果设置enable_seqscan=off，则表示不会优先选择Seq Scan，而不是一定不会选。扫描方式的选择，很大程度上决定了获取基表数据的路径。lineitem分布键是l_orderkey，并且在l_orderkey上有index，orders分布键是o_orderkey。lineitem的扫描变成了Index Only Scan（因为l_orderkey的类型是int），而在orders表上仍然选择Seq Scan（因为没有其他路径），同时关联方式也变为了Nest Loop，因为Hash Join需要全表扫描数据（lineitem的Seq Scan已经被关掉了）。优化器的选择方式我们从代价（E-costs）一栏中也可以看出。从代价上看出Hash Join的总代价比Nest Loop的小，但优化器没有选择Hash Join，这是因为优化器比较路径代价时，会比较Startup和Total代价，即启动代价和总代价，综合考虑，E-costs栏中显示的是总代价。扫描路径的调控，可以改变路径生成，合理的搭配是生成最优计划的前提，默认情况下，GaussDB优化器可以根据现有的路径选择（如上面的lineitem有两条扫描路径，orders只有一条扫描路径），最后确定出最优的一条。两条路径代价比较时，总代价不是唯一要素，但总代价越小，一般也会越容易被选中。

路径生成是表关联方式确定的主要阶段，影响路径生成的要素：cost_param, scan方式，join方式，stream方式，并从原理上分析如何干预路径的生成。从另外一个角度看，即路径生成，是从这些底层的选择开始，从行数的估算、到scan的选择、再到join方式以及stream的选择，构成一条简单路径，然后多条路径根据代价选择，再逐层关联更多的表，最终形成一个完整的执行路径。 cost模型选择顾名思义，cost_param是控制cost相关的一个参数。在了解cost_param前，先回顾一下选择率的概念，GaussDB优化器中的选择率是指，当一个表有一个过滤或关联条件时，通过该条件能被选中的行数占总行数的比例，是介于0~1之间的一个实数。选择率在优化器中是一个重要的概念，主要应用于行数和distinct值的估算，行数和distinct值是计划生成中的基本要素。首先，我们来看带有过滤条件的基表行数如何估算。如果一个表只有一个过滤条件，那么以选择率乘以表的行数，即可得到过滤完的行数；如果有多个过滤条件，那么就需要算出一个综合的选择率，如何计算？方式有二：一是通过多列统计信息直接计算，二是通过组合单列的选择率。那么组合的方式就由参数cost_param决定了，具体地： 取值描述适用场景cost_param = 0选择率按乘积方式组合完全不相关场景cost_param & 2 != 0取最小的选择率作为综合选择率完全相关场景从估算出的行数（E-rows）和实际的行数（A-rows）对比可以看出，cost_param=0的不相关模型适合part表的p_brand和p_container列。其次，Join的行数怎么估算的呢？原理跟过滤条件的行数估算是类似的，如果没有多列统计信息可以使用，则也需要单独计算每个条件的选择率，然后计算出综合选择率，得出行数。由于TPC-H的模型接近完全不相关模型，因此cost_param=0模型可以较好的描述场景，实际应用中，用户可以根据具体业务场景来调整模型，行数估算的准确性是计划生成的重要保证，在调优中检查估算的最直接的地方。GaussDB会在后续版本中新增更多模型供业务需求选择。

      用户在使用数据库过程中，常常受限于内置函数的功能，部分业务不易实现，或实现后性能较差，在这些场景出现时可以考虑使用C编写自定义函数来实现独立功能。        例如用户针对某些数据列需要使用C编写的特定算法进行计算，如果放在业务层所性能不能接受，就可以尝试有自定义C函数在实现功能的前提下保证实现效率。       粗略的来说，用户使用C编写的自定义函数会被被编译成动态库并且由数据库在需要的时候载入。在一个会话中第一次调用一个特定的用户定义函数时，数据库进程会把动态库文件载入到内存中以便该函数被调用。从这个角度来说，注册自定义函数时需要准备编译好的动态库文件和函数定义。数据类型      首先需要先明确，数据库中支持的数据类型在使用自定义C函数操作时，必须将数据库中的数据类型转换为数据库内核可以处理的相关类型，实际上数据库内核在处理内置函数输入时也是类似的操作：例如比较常见的：sql类型C类型smallintint16integerint32bigintint64texttext*      常见的几种类型中，需要注意的是，对text类的函数，C函数在实际处理时往往不是直接使用 gaussdb 内部的 text\* 类型进行处理的，而是使用C语言的标准类型 char\* 进行处理的。      这种情况下就可以先读取到入参的地址，再通过gauss提供的内置C函数(比如简单常用的TextDatumGetCString)转换为 char\* 类型字符串进行操作。 应用实例      下面以两个简单的HelloWorld例子来说明自定义C函数创建的整体流程。1. 最大公约数      最大公约数的计算比较简单，但内部必然会涉及循环，使用SQL实现只能通过类似PL/pgSQL自定义函数或存储过程的方法，如果要达到极限性能的话可以尝试使用自定义C函数实现。 自定义C函数的存在给用户提供了直接实现底层逻辑的机会，一个实现完善的自定义C函数，往往可以给业务带来极强的定制性和大幅度的性能提升。但定制性也是一把双刃剑，如果编写自定义C函数时做的不够完善存在逻辑问题，甚至内存溢出等严重问题，也极可能使系统崩溃。因此可以使用自定义C函数作为一个强有力的工具为实际业务增光添彩，但也需要谨慎的创建使用任意一个C函数避免误伤其他业务。

 通过开启use_workload_manager和enable_dynamic_workload两个参数开启GaussDB(DWS)的内存自适应控制机制。      使用内存自适应机制时，打印SQL语句的explain performance执行计划运行信息时，会包含以下额外的信息辅助定位问题：    （1）在最下方的Query Summary一栏中，会显示出System available mem、Query max mem和Query estimated mem，分别表示：系统当前可用内存、语句可用最大内存（系统可用最大内存），语句估算内存使用量，均为单DN的衡量值。下图表示当前语句的语句最大可用内存和系统当前可用内存均为22G，语句估算内存使用为1.6G。（2）在Memory Information一栏，会显示CN和每个DN的内存使用峰值，如下图所示，语句实际内存使用，单DN使用16GB，CN使用76MB。                         （3）在Memory Information一栏下方每个算子对应的位置，会显示每个算子单DN的内存峰值，同时会显示每个DN上内存使用的自动扩展和提前下盘情况，例如下图，可以看出第15号HashJoin算子，每个SMP线程的内存使用均为3.8GB，估算内存是860MB，经历了五次内存自动扩展，在第五次扩展后，系统内存告急，算子未用到第五次扩展后的峰值即提前下盘。     （4）在explain performance最顶层的表格中，汇总了每个算子的估算内存和实际使用内存的情况，见下图的E-memory和Peak Memory两列所示。与上面信息对应，第15号算子单SMP线程的peak memory，最大值为3766MB，最小值为3753MB，估算内存值（单DN4个SMP线程）为860MB。      可以看出，上面例子由于cost估算不准导致内存估算值较小，实际场景也会出现内存估算值较大的场景，会导致CCN预留内存较多，阻塞其它作业的执行。因此，可以使用参数query_mem来控制语句最大可用内存上限（单DN），相当于代替了Query max mem。此参数默认为0，表示未开启。当此值大于32MB（最小语句内存分配值）时，表示开启，此时使用work_mem控制系统当前可用内存进行估算，相当于代替了System available mem进行估算。此时，CCN会使用query_mem值进行语句内存估算值的预留和排队，提高并发场景下的内存使用效率。