这张时序图比较大，但是大致上描述了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。
------------------------------------华丽丽的分割线------------------------------------
------------------------------------华丽丽的分割线------------------------------------