这张时序图比较大，但是大致上描述了PG 处理简单SQL的大致流程。

      由客户端发起SQL 语句，PG服务端进程backend接收到语句后，开始执行exec_simple_query()代码。后面所有方法调用均有exec_simple_query()函数直接或者间接发起。

大体上分为以下几个过程：pg_parse_query()->pg_analyze_and_rewrite()->pg_plan_queries()->… ExecutePlan() … ->pg_report_stat()。

pg_parse_query

    只是简单的产生raw parse tree，这个里面不涉及语义检查。只是做语法扫描，是一个Bison parser。

pg_analyze_and_rewrite

    这块会进行语义分析，会访问数据库中的对像，需要持有锁。这个过程会将简单的一个select 语句拆分成多个部分，将parse tree转换成query tree。如将整个select语句转换成：from 部分，

where条件部分，group by 部分，order by 部分以及having 部分等。是任何数据库都需要操作的，并且非常重要的一环。 

pg_plan_queries

    在这个环节，将根据上面的query tree产生执行计划。这部分核心代码在planner.c中，是PG的Query Optimizer。会根据表和索引的统计信息去计算不同路径的可能代价值，最后选出最优者。

这里先不展开，后面会写文章，专门讲这块，即“PG 的Cost-based Optimizer原理”。

ExecutePlan

    执行plan，它会遍历每个节点，以致完成。最后将查询结果返回给客户端。

pg_report_stat

    将统计信息发送给collector。比如说表和索引扫描了多少次，返回多少记录等。如果是DML语句，还会有增删除改多少记录的统计信息。原始信息以表为维度，后面汇总到库级别或者实例级别。

这对于健康检查或者监控PG的性能有非常重要的作用。

    从下面时序图中，可以看出，每个源码文件的任务非常清晰。

postgres.c: 为backend进程，负责打杂和调度，是与客户端对应的server进程。因为PG是C/S架构的，每个客户端连接到PG后，postmaster都会fork出一个backend进程与之进行交互。

xact.c：是与事务相关的操作。事务的状态标志，隔离级别，是否有嵌套事务等。

utility.c: 语句或者命令的类型，主要包含delete,insert,update,select,explain,create,alter等。

execMain.c：是执行语句的总调度入口。

pgstat.c：负责数据库统计收集和展示。

portalmem.c：负责语句执行时，内存申请与释放。PG中，专门取了一个名字叫portal，相当于workspace。