每种数据库都有自己的SQL执行流程图，PostgreSQL也不例外。下面这张图基本上概括了PG处理SQL的整个逻辑。我下面分开来细讲一下：
1.main
main是整个后台的入口，基本上不处理任何逻辑，只是简单的分发处理逻辑。
但是像检查当前用户是否是”root”，还是会做的。因为我们知道，root用户是不能起动PG server的。
2.Postmaster
著名的postmaster 后台进程就是由此代码实现的。这个代码封装了PG所有后台进程的入口。这里为什么只是说“入口”呢，因为实现由各自的代码文件实现。这里不
负责。如像checkpoint进程，bgwriter进程，wal writer进程，autovacuum laucner进程，stats collector进程以及archiver进程等。这些进程都是有postmaster
fork出来。另外postgres用户进程，vacuum worker进程等也是由postmaster进程负责fork。除此之外，postmaster 还负责监听用户请求，将用户请求从监听端口中
接收过来，fork出一个postgres进程，专门负责处理用户SQL语句。由此可见，这个代码的重要性。
3.postgres
postgres是用户进程，专门负责处理用户请求。也就是通常所说的backend进程。用户终端在上一步postmaster fork出postgres backend进程后，直接与此postgres 进程交互。
无论是后台进程还是backend 进程，都由postmaster来维护。postmaster在全局级别维护了一个数组，为每个进程分配一个slot。
4.Parse statement
postgres进程被fork后，接受用户并处理用户语句。因此这里首先会识别用户所发出的语句。如insert,delete,update,select等DML语句，另外还有如create table,create index等DDL语句。
只是识别语句的类型，并不会做其他任何处理。然后由traffic cop 代码块进行分发。
5.traffic corp
这步最主要的使用就是根据不的语句类型分发到不同代码进行处理。所以称作为traffic corp，也就是交通协调疏导的意思。如果是DML语句或者是select 语句，都属于QUERY，进入QUERY处理
逻辑。如果是DDL语句，那么属于Utility Command，进入Utility Command处理逻辑。因为DDL与DML的处理逻辑是非常不一样的。
6.Query Rewrite & Generate Path
进入QUERY逻辑后，接着就是rewrite动作。rewrite就是改写SQL语句并将用户请求的SQL做一些简单的优化处理。PG的语法和语义检查，是在这里做的。具体来讲，这段代码由execute_simple_query
方法来实现。先进行raw parse，简单的将语句进行分析，生成parse tree，也就是语法树。后面再经过analyze和rewrite，生成query tree，即查询树。查询树的生成需要进行语义检查。
会检查数据库对象，因此会有上锁的逻辑。这一步会调用optimizer，并根据cost选择一种最优的执行路径。
7.Generate Plan
根据最优路径，生成执行计划和执行树。
8.Execute Plan
执行执行树的每个node，最终返回结果给用户terminal。到这里整个执行逻辑基本上就是结束了。
从上面看来，是否跟Oracle非常像。只是Oracle把监听的功能独立出来，放到listener中了，这有利于整个系统的稳定性。另外上面图中还列许多其它的代码块，如Catalog,Storage Manager,
Access Method等。Catalog主要是负责数据字典和元数据管理。Storage Manager负责存储介质管理，实现了将buffer page映射到物理磁盘上的文件，同步缓存与磁盘文件等功能。
Access Method主要实现了访问路径的实现，如index scan, heap scan等。
PG是基于进程架构的，因此每个用户请求在后台都有一个专门的backend进程与之对应。与MySQL基于线程架构的区别以及优缺点，相必大家也比较清楚。总体上来讲，基于进程架构的系统更稳定；
但是连接内存开销上会大些。基于进程架构的系统，在源码开发以及内存变量处理上比较复杂些。多进程IPC通信处理等，需要额外关注比较多。
转载于:http://blog.itpub.net/30088583/viewspace-1715489/