PostgreSQL的Backend目录
作者:Bruce Momjian
bootstrap - 通过initdb创建最初的数据库模板
几乎PostgreSQL的每一个操作都需要存取系统表,那么如何创建这些系统表呢?不能以通常的方式创建这些系统表并向其中插入数据,因为表的创建和插入要求系统表已经存在。这一部分代码的目的就是使用一种仅仅在bootstrap过程中使用的特殊方法来直接建立系统表
main - 将控制转到postmaster或postgres
检查进程名(argv[0])和各种标志, 然后将控制转到postmaster或postgres
postmaster - 控制postgres服务器启动/终止
创建共享内存,然后进入一个循环等待连接请求。当一个连接请求到达时,启动一个postgres后台服务进程,将连接转给它
libpq - 后台服务器libpq库函数
处理与客户进程间的通讯
tcop - 将请求分派到合适的模块
这是postgres后台服务进程的主要处理部分, 它调用parser, optimizer, executor, 和commands中的函数
parser - 将SQL查询转化为查询树
将来自libpq的SQL查询转换为命令形式的结构供optimizer/executor或commands使用.首先对SQL语句进行词法分析,转换为关键字,标识符和常量,然后进行语法分析。语法分析生成命令形式的结构来表示查询的组成。然后这个命令形式的结构被分离、检查和传送给commands中的处理函数,或者转换为结点链表供optimizer和executor处理
optimizer - 创建查询路径和查询计划
使用parser的输出来为executor生成优化了的查询计划.
optimizer/path - 使用parser的输出创建查询路径
它使用parser的输出生成所有可能的执行方法,它检查表的连接顺序,where子句限制和optimizer的表统计信息来评估每一个可能的执行方法,并赋予每个方法一个代价
optimizer/geqo - 遗传算法查询优化
optimizer/path 对所有连接表的方法进行了评估。但是当表的数目变得很大时,检测测的数目也会变得很大。遗传算法查询优化对每一个表进行考虑,然后计算出最优的顺序来执行连接。如果只有几个表,这种方法花费较长的时间,但对于大量的表,这种方法就比较快了。系统有一个选项用于控制何时使用这个功能
optimizer/plan - 优化path输出
为optimizer/path的输出选择代价最小的路径并创建一个执行计划
optimizer/prep - 处理特殊的查询计划
对特殊的查询计划进行处理
optimizer/util - 优化器支持函数
供优化器其他部分使用的函数
executor - 执行来自optimizer的复杂的节点形式的查询计划
处理select, insert, update,和delete语句. 处理这些语句的操作包括堆扫描、索引扫描、排序、连接表、分组、计算集函数和唯一性处理
commands - 不需要executor执行的命令
执行不需要复杂处理的SQL命令.包括vacuum, copy, alter, create table, create type以及许多其他未能例举的命令。调用这一部分代码时使用由parser生成的结构.大多数的函数先做一些处理,然后就调用catalog目录下的一些低层函数来做实际的工作
catalog - 系统目录操作
包含用于操作系统表和系统目录的函数.表、索引、过程、运算符、类型、和集函数的创建和操纵函数在这里可以找到。它们都是低层的函数,通常由上层将用户请求格式化为预定义格式的函数调用
storage - 管理各种类型的存储系统
支持服务器以统一的方式存取资源
storage/buffer - 共享缓冲区管理
storage/file - 文件管理
storage/ipc - 信号灯和共享内存
storage/large_object - 大对象
storage/lmgr - 锁管理器
storage/page - 页管理器
storage/smgr - 存储/磁盘管理器
access - 各种存取方法
支持堆, 索引, 和事务对数据的存取
access/common - 公共存取函数
access/gist - 可自定义的存取方法
access/hash - hash
access/heap - 堆用于存取表
access/index - 所有索引类型都使用
access/nbtree - Lehman and Yao的btree管理算法
access/rtree - 用于索引2维数据
access/transam - 事务管理器(BEGIN/ABORT/COMMIT)
nodes - 创建/操纵节点和链表
PostgreSQL将SQL查询存储到称为节点的结构中。节点是通用的容器,它包含一个类型字段和一个与类型有关的数据字段.节点通常串成链表。
链表包含一个元素和一个next指针.节点和链表广泛的用于parser,optimizer,和executor中用于存储请求和数据
utils - 支持程序
utils/adt - 内建数据类型
包含所有PostgreSQL自带数据类型
utils/cache - system/relation/function高速缓存
PostgreSQL 支持自定义数据类型,因此没有数据类型是固化在核心当中的。当服务器需要查找一个数据类型时它就到系统表中去找。由于系统表频繁使用,所以设立一个高速缓存来加速查找。系统中包括一个系统关系cache, 一个函数/运算符cache和一个关系信息cache. 关系信息cache中包含所有最近访问过的表的信息而不仅仅包含系统表的信息
utils/error - 错误报告
向前台报告后台错误
utils/fmgr - 函数管理器
处理动态加载函数的调用和在系统表中定义的函数的调用
utils/hash - 内部使用的hash程序
用于cache和内存管理器以便快速查找动态存储的数据结构
utils/init - 各种初始化
utils/misc - 未归类的东东
utils/mmgr - 内存管理器(进程私有内存)
PostgreSQL在显式的内存上下文中分配内存. 上下文可以是语句级、事务级或永久/全局级的.这样,后台服务器可以很容易地在一个语句或者事务结束的时候释放内存
utils/sort - 排序
在内存中或者使用磁盘文件排序
utils/time - 事务时间限定
检查元组是否仍然有效,还是属于未提交事务或者已被新行替代
include - 包含文件
每个子系统有一个目录
lib - 支持库
几个通用的程序
regex - 正规表达式库
用于后台服务器的正规表达式处理如'~'.
rewrite - 规则系统
完成规则系统的处理
tioga - 未用
上面是翻译的PG的文档,原文在~/Postgresql/source/src/tools/backend/index.html
组成postgresql后台进程的源代码都在~/Postgresql/source/src/backend目录下,上面这份文档中的小节标题就是子目录名称。面对着这份文档,该从哪里下手呢?我觉得所有服务器源代码大致可以分为四个组成部分:工具部分,查询处理部分,事务存储管理部分,系统初始化部分。工具部分基本集中于utils目录下,对于新手,可以由此入手感觉一下,例如分析分析mmgr的对外接口和内部实现算法。查询部分主要是 tcop/rewrite/parser/optimizer/executor/commands等等。我打算从事务存储管理部分入手分析,主要的代码集中在storage/access之下。系统初始化部分最好到最后在分析。上面讲的还只是后台服务器,其他还有一些东东如odbc/jdbc、各种语言接口、管理工具如pgAdmin/pgAccess等等
卡牌构筑类游戏小结
16 小时前
没有评论:
发表评论