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值进行语句内存估算值的预留和排队，提高并发场景下的内存使用效率。

（1）对于每个SQL，生成计划前首先从资源管理模块获取系统当前的最大可用内存（Query Max Mem）和当前可用内存（System Available Mem）。最大可用内存通常为每个DN的最大可用内存去除系统预分配内存，例如：数据缓存等，表示语句可用的最大内存，如果语句使用内存超过该值，必须下盘。当前可用内存用于表示当前系统的繁忙程度，如果当前可用内存比较小，倾向于选择耗费内存少的计划。（2）依据当前可用内存生成计划，同时根据SQL引擎优化器计划生成过程中的cost估算值估算每个物化算子的内存使用量，以及流水线场景下整个查询使用的内存总量估算值。如果该值大于当前可用内存，则尝试将整个查询的内存使用量调到当前可用内存以下，此时会造成部分算子下盘。（3）将语句及估算的语句内存发送到CCN，如果当前可用内存小于语句估算内存，则估算语句的内存进一步减少是否对查询性能造成较大的影响，如果根据cost评估影响不大，则进一步减少算子的内存使用，使语句内存使用满足当前可用内存，将语句下发执行，否则则进入排队状态。（4）由于每个算子的内存使用量是基于cost评估获得，可能存在一定的误差。因此，在SQL语句执行时，支持内存的动态调整，包括：执行算子内存的自动扩展和提前下盘。当算子达到估算的内存值上限，但系统还有宽裕的内存时，会进行算子内存的扩展，继续保持不下盘的状态。当系统已用内存达到80%或更高时，如果算子已有最小内存保证，则会触发提前下盘逻辑，保证不会由于内存不足而报错。

GaussDB(DWS)的静态内存管理存在较大弊端，需要调优人员能够根据数据量、语句复杂程度和系统的内存大小设置合理的work_mem，既避免work_mem设置太大导致系统资源不够用，还要考虑到数据规模，保证大部分算子不下盘。通常情况下，这个是很难做到的，有以下几点原因：（1）通常情况下，复杂语句的执行计划中包含多个复杂算子，每个算子的内存使用上限是work_mem，我们没有办法计算一个语句要使用多少内存，因此也就不容易设置一个最优的work_mem参数，保证尽可能不下盘，同时内存又够用。并发场景更无法设置了。（2）work_mem只是每个算子内存使用的上限，并不是预分配；如果数据量没有那么大的话，实际内存使用是达不到work_mem的。因此也会影响work_mem的设置。（3）每个语句的场景不一样，有的语句包含多个物化算子，而另外的语句只有一个物化算子，而这个算子对内存的需求会比较大，因此无法全局统一地进行设置。GaussDB(DWS)的内存自适应技术介绍针对静态内存管理机制的弊端，我们设计了内存自适应控制技术，目的有两个：（1）去除静态内存管理对work_mem的依赖。可以由SQL引擎优化器模块自动估算每个算子所需的内存。（2）避免大并发场景下内存不足现象的发生。资源管理模块根据SQL引擎优化器对于每个查询内存的估算值，对每个查询进行调度，如果超过系统可用内存，则进行排队。

在SQL语句复杂、处理数据量大的AP场景下，单个查询对内存的需求越来越大，多个语句的并发很容易将系统的内存吃满，造成内存不足的问题。为了应对这种问题，GaussDB(DWS)引入了内存自适应控制的技术，在上述场景下能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。GaussDB(DWS)的静态内存管理机制及缺陷GaussDB(DWS)的执行引擎继承自PG，对于优化器生成的执行计划树，总体采取执行算子+流水线的处理方式，如下图所示。对于NestLoop算子节点，需要首先从左树的IndexScan算子节点获取元组，然后到右子树的IndexScan算子节点进行连接，匹配元组后进行输出。      流水线的执行方式使得对于NestLoop, IndexScan类的一般算子，同时只有一定数量的元组处于内存中，对于行引擎每个算子仅占用一条元组的空间，对于列引擎占用一个batch（最多1000条元组）的空间，占用的空间较小，基本可以忽略不计。      但是，GaussDB(DWS)中也有一些需要将所有数据收集后进行处理的算子，在执行时需要使用较多的内存，通常我们称这类算子为物化算子。GaussDB(DWS)中主要存在如下不同种类的物化算子：（1）HashJoin：Hash连接操作符，主要思想是计算左右两表连接列的hash值，通过hash值比较减少元组比较的次数，需要将一个表建立hash表，另一个表进行hash值比较操作，建立hash表需要在内存中进行。（2）HashAgg：Hash聚集操作符，主要思想同HashJoin类似，通过hash值比较减少元组去重比较的次数，需要将不同值的元组保存的内存中。（3）Sort：排序操作符，需要获取所有元组后进行排序操作，待排序元组均存在于内存中。（4）Materialize：物化操作符，通常在需要重复扫描时使用，通过将结果存储在内存中，保证重复扫描时的效率。      同时，GaussDB也提供下盘的机制，当上述操作符需要使用的内存太大时，可以将部分或全部的数据下盘处理，提高内存的使用效率，但相应的查询性能也会受到影响。PG使用 work_mem参数来控制算子可使用内存的阈值，当使用内存超过阈值时，就需要做下盘处理。GaussDB(DWS)的静态内存管理机制也延续了PG的处理机制，使用work_mem来控制单算子的内存使用上限。