肥叔菌的博客

如果一个事务没有进行INSERT、UPDATE、DELETE操作，那么就步会分配事务ID，但事务仍然用一个虚拟事务ID代表自己。虚拟事务ID由两部分组成，第一部分是Backend ID，另一个是每个会话自己维护的本地事务ID计数器。通过两部分组合，能保证这个虚拟事务ID的唯一性。在PostgreSQL数据库IPC——SI Message Queue中描述了Backend ID和local transaction id的产生流程。

SI Message Queue代码位于src/backend/storage/ipc/sinvaladt.c和src/backend/storage/ipc/sinval.c文件中，属于PostgreSQL数据库IPC进程间通信的一种方式【之前介绍过PostgreSQL数据库PMsignal——后端进程\Postmaster信号通信也是作为PostgreSQL数据库IPC进程间通信的一种方式，主要用于进程间信号通信】，主要用于POSTGRES shared cache invalidation共享缓存失效

如上图所示是将plan_dxl转为plan_stmt的主入口函数。其主要工作就是创建plan_id_generator、motion_id_generator、param_id_generator和table_list、subplans_list，并将其设置到CContextDXLToPlStmt dxl_to_plan_stmt_ctxt中供后续流程调用；初始化CTranslatorDXLToPlStmt类，形参为MDACCESSOR和CContextDXLToPlStmt；

将dyn_foreign_scan的foreignscan成员设置为foreign_scan_first_part，将dyn_foreign_scan->foreignscan.scan.plan.type设置为T_DynamicForeignScan，将dyn_foreign_scan->foreignscan.scan.scanrelid设置为index。1 提取形参tbl_scan_dxlnode有效信息【获取CDXLNode的m_dxl_op成员，转化为CDXLPhysicalTableScan；

下面是ErelstorageVirtual存储类型所涉及到的代码：CTranslatorRelcacheToDXL::RetrieveRelStorageType Get relation storage type根据存储类型字符获取其Erelstoragetype枚举类型。该枚举类型应该是不用的。从上面的对比可以看出AP7将分区表子分区混合存储这种情况单独作为了一种存储类型ErelstorageMixedPartitioned。

CXforml类作为所有transformation的基础类，其包含了pattern成员m_pexpr。主要是在exploration和implementation expression流程中使用，主要调用Transform函数。其还包含返回相关xforms的集合函数，比如PbsIndexJoinXforms等。

一旦当前子组优化任务完成，它将检查继续是否有意义（例如，我们是否为前一个子组找到了有效的计划，以及我们是否已经超过了成本限制）。Once the group exploration of the children is done, the expression exploration job schedules all applicable exploration transforms for this expression. 一旦完成了子对象的组探索，表达式探索作业就为该表达式安排所有适用的探索转换。

但是该函数在greeplum使用orca优化器流程中都没有调用，因为ScalarFilter是在Expr Tree转化为DXL Tree的流程中创建的，而非在QueryToDXL流程中调用，因此Query树中的qual表达式是被转化为其他CDXLScalar子类，而不是CDXLScalarFilter。CDXLScalarFilter相对于CDXLScalar没有增加其他数据成员。CDXLScalarFilter及其子类在CTranslatorExprToDXL流程中实例化，调用流程如下所示。

CDXLScalar类作为Base class for representing scalar DXL operators，该类只是定义一些接口，其中实现了GetDXLOperatorType函数，其返回EdxloptypeScalar，代表scalar DXL operators。

如上图所示，CDXLOperator作为Base class for operators in a DXL tree，其子类CDXLLogical、CDXLScalar、CDXLPhysical作为逻辑节点、物理节点和Scalar节点的DXL表示类，因此其包含了这些类的共同部分特性，比如获取其DXL节点表示的函数GetDXLOperator、获取其Operator类型的函数GetDXLOperatorType，如下图右侧所示。，即为AggFunc。

从代码实现可以看出其也是通过CExpressionHandle接口来获取对应子表达式的CFunctionProp function properties，从而获取其易变属性值的。而COperator::PfpDeriveFromChildren则是调用EfsDeriveFromChildren函数获取易变属性，然后调用CFunctionProp构造函数创建函数属性变量。只要子表达式中的函数出现易变属性，将会掩盖其他函数的非易变属性。

Instead of rewritten parse tree, will use the term query tree going forward. In order to view the below serialized DXL Representation (generate the minidump) of the query tree, do the following:If the GUC optimize_minidump=always is not set, the Query Tre

从ORCA优化器浅析——重要主流程概述中可以知道进入真正优化器引擎执行流程之前需要对优化器提出要求，比如后面会提到的required columns、required sort orders等。首先CQueryContext类是通过PqcGenerate函数构造的，其函数签名如下。由于CQueryContext实例将在CEngine::Init流程中被赋值给CEngine的m_pqc成员，所以CQueryContext对优化器的要求也将由CEngine管理，通过对m_pqc的跟踪，其主要调用的函数是。

优化流程的重要函数如上所示，首先需要介绍一下最重要的类CSchedulerContext，如下图右上角所示，其包含三个重要成员：CJobFactory *m_pjf【生成CJOB任务类实例的工厂函数】、CScheduler *m_psched【调度器类用于调度任务类实例】、CEngine *m_peng【Optimization engine】。m_pexprBest用于存放当前search stage的最佳执行计划，m_costBest用于存放当前search stage的最佳执行计划的COST。

dsm.c提供的功能允许创建后端进程间共享的共享内存段。DSA利用多个DSM段提供共享内存heap；DSA可以利用已经存在的共享内存（DSM段）也可以创建额外的DSM段。和系统heap使用指针不同的是，DSA提供伪指针，可以转换为backend-local指针，但是该伪指针可以在后端进程之间共享，可以用于构建共享数据结构。每个DSA管理多个DSM段，可以向其中添加新段，不需要时detach它们。

Orca是Pivotal数据管理产品的新查询优化器，包括GPDB和HAWQ。Orca是一个基于Cascades操作时序框架的现代自上而下的查询优化器。虽然许多Cascades优化器与其主机系统紧密耦合，但Orca的一个独特功能是它能够作为独立的优化器在数据库系统之外运行。这种能力对于使用一个优化器支持具有不同计算架构（例如MPP和Hadoop）的产品至关重要。它还允许在Hadoop等新的查询处理范式中利用关系优化的广泛遗留问题。

【代码】ORCA优化器浅析——Query Life Cycle。

【代码】ORCA优化器浅析——How to use ORCA on Greenplum。

【代码】ORCA优化器浅析——What is a Query Plan。

GPORCA，规则分为两类：Exploration，是对逻辑表达式做等价变换的；Implementation，是把逻辑操作符转换为物理操作符。由于Exploration和Implementation流程一致，因此合在一起描述主要流程：（本篇文章仅关注第一步和第二步）

CJobGroupExpressionExploration类作为Explore group expression optimization job，主要负责创建给定组表达式的逻辑重写。

内容摘自。

从src/backend/gporca/libgpopt/src/mdcache/CMDAccessor.cpp/CMDAccessor::GetImdObj(IMDid *)函数来看，object not found in MD cahce: retrieve it from MD provider来看，就是从MD CACHE中找不到对应的对象就从MD provider中获取，代码中使用了timeFetch CTimerUser来统计开始结束时间差，如下代码所示。

图9显示了Orca如何与不同的后端系统交换元数据。对元数据对象的所有访问都是通过MD访问器完成的，该访问器跟踪优化会话中访问的对象，并确保在不再需要它们时释放它们。GetMDObjDXLStr函数是MD Provider中最重要的函数，为了适配不同的MD Provider，但是GetMDObjDXLStr函数需要提供对MDObj的统一封装，因此ORCA给的方法是将MDObj中的信息序列化为DXLStr(其实就是xml)并返回CWStringBase，这样就无需返回统一的MDObj基类。

Path表示了一种可能的计算路径（比如顺序扫描或哈希关联），更复杂的路径会继承Path结构体并记录更多信息以用于优化。。Greenplum中表的分布键决定了元组存储时的分布情况，影响元组在那个segment的磁盘上的存储。CdbPathLocus决定了在执行时一个元组（元组可能来自表，也可能来自函数）在不同的进程间（不同segment的QE）的重分布情况，即一个元组该被哪个进程处理。

首先我们需要看CGPOptimizer类(src/include/gpopt/CGPOptimizer.h)为Greenplum数据库提供ORCA优化器export出来的函数的封装。Greenplum数据库主流程调用extern "C"中提供的函数，比如初始化ORCA优化器的函数InitGPOPT，优化查询树的函数GPOPTOptimizedPlan，explain流程中调用的SerializeDXLPlan函数。

首先看一下metadata cache中metadata-related objects对象的Base接口IMDInterface，metadata中所有对象的父类，代码位于src/backend/gporca/libnaucrates/include/naucrates/md/IMDInterface.h文件中。再看一下metadata cache中。

我们假设已经应用了eval_const_expression()，因此不存在未展开的and或or（例如，在and中没有立即的and，包括顶级List结构下方的and）。如果这不是真的，我们可能无法证明一个有效的暗示，但不会产生更糟糕的后果。可以refute推导两个表达式树的叶子节点之间的是否排斥(atom A R=> atom B iff: predicate_refuted_by_simple_clause says so)，然后叠加上父节点的AND或OR关系，确定两个表达式树在该中继节点上是否排斥。

从上述执行计划对比可以看出，Postgresql优化器中每个分区子表都对应一个SeqScan，并由Append节点串联；而再ORCA优化器中，Dynamic Seq Scan则包含了分区裁剪后所有分区子表的扫描动作。这里主要描述Dynamic Seq Scan的执行流程，后续会关注Partition Selector节点。用于将DXL dynamic table scan节点转化为DynamicSeqScan节点，以提供给执行器执行。

前面的博客PostgreSQL数据库查询执行——SeqScan节点执行介绍了SeqScan节点的执行，该博客主要集中于描述execScan谓词过滤的执行。此代码提供对generalized relation扫描的支持。ExecScan被传递一个节点和一个指向函数的指针，以“做正确的事情”并从关系中返回一个元组。ExecScan然后做一些乏味的事情——checking the和适当地the tuple。

在扩展后运行ANALYZE更新表的统计信息，默认是不运行ANALYZE。在暂停一秒钟之前发送给给定主机的远程命令的批量大小。默认值是16， 有效值是1-128。gpexpand工具会发出许多设置命令，这些命令可能会超出主机的已验证 连接的最大阈值（由SSH守护进程配置中的MaxStartups定义）。该一秒钟 的暂停允许在gpexpand发出更多命令之前完成认证。默认值通常不需要改变。

filesystem interface代码定义在pgsql/src/backend/storage/file/filesystem.c文件中。首先介绍哈希表(filesystem hash table)，其key为代表FsysName的字符串(filesystem name)，value为FsysInterface结构体。FsysInterface结构体包含了filesystem interface所抽象的函数不同文件系统的具体实现函数。

src/backend/tcop/utility.c/ProcessUtility函数在T_DefineStmt分支中处理stmt->kind为OBJECT_FILESYSTEM会调用src/backend/commands/filesystemcmds.c/DefineFileSystem函数(src/bin/gpfilesystem/hdfs/gpfshdfs.c文件为GPDB提供HDFS filesystem interface，其使用libhdfs库与HDFS通信。

在本文的前面，我们看到，对于Hive表，用户通常需要知道表的潜在的不直观的物理布局，以便获得更好的性能。Iceberg提供了不断向用户公开逻辑视图的能力，从而将逻辑交互点与数据的物理布局分离开来。我们看到了这对于隐藏分区和压缩之类的功能是多么有用。Iceberg通过模式演化、分区演化和排序顺序演化功能，提供了随时间透明地演化表的能力。有关这些的更多详细信息，请访问冰山文档网站。对于数据工程来说，在幕后尝试不同的、可能更好的表布局要容易得多。一旦提交，更改将生效，用户无需更改其应用程序代码或查询。

通过pg_exttable系统表确定数据源格式（text/csv–>TEXT；avro–>AVRO；将env_cmd.data, java_cmd, format, gp_hadoop_connector_version, url, table_schema.data, table_attr_names.data序列化为cmd，最后调用。gphdfs_fopen函数通过调用hadoop_env.sh脚本建立Hadoop环境变量（env_cmd环境变量命令为。

Greenplum Database（下面简称GPDB）主要提供了两种方式：PXF和GPHDFS。虽然二者都利用了GPDB的外部表功能，但是前者需要额外安装部署PXF服务器进程，在复杂的IT环境中流程繁琐、极易出错，终端用户体验不佳。GPHDFS通过增加一种访问HDFS的外部表协议，让各个计算节点直连HDFS集群，不通过任何中间节点或者系统。

该篇博客主要关注src/backend/access/external/fileam.c文件，其封装了底层获取数据和流控的实现细节，为上层执行节点提供抽象API（SCAN、INSERT功能）。

所以，在初期规划和实现HashData数据仓库访问HDFS的功能时，即采用GPHDFS的技术路线：通过增加一种访问HDFS的外部表协议，让各个计算节点直连HDFS集群，不通过任何中间节点或者系统，大幅降低使用门槛的同时，保证两个系统之间数据交换的效率。其次，引入类似Oracle数据源配置文件的gphdfs.conf文件，将多个HDFS系统相关的访问信息集中起来，简化访问配置的管理；技术架构层面，HashData的GPHDFS实现跟GPDB的GPHDFS是一致的，更多的差异是体现在实现细节层面。

通过protOid删除相应的外部协议。首先以RowExclusiveLock打开pg_extprotocol系统表，并利用ExtprotocolOidIndexId进行扫描，获取protOid对应的条目，并调用CatalogTupleDelete函数进行删除。LookupExtProtocolFunction函数主要是在src/backend/access/external/url_custom.c文件的url_custom_fopen --> LookupExtProtocolFunction中调用。

使用libcurl库创建的资源（主要是curl 句柄和headers列表）需要在出错时主动去清理，所以greenplum利用了resource owner机制（当释放ResourceOwner时，自定义的回调函数可以用来清理libcurl库创建的资源）。greenplum使用curlhandle_t结构体将curl 句柄和headers列表等将curl相关资源封装在一起，并利用open_curl_handles双向链表来组织当前正在使用的libcurl库创建的资源。libcurl库创建的资源使用双向链表