面向进程模型是一种数据库系统的架构模型，核心思想是将不同的数据库服务分配给不同的进程，每个进程独立运行，相互之间通过进程间通信（IPC）进行协作。这种模型被广泛应用于数据库系统中，例如 PostgreSQL 数据库系统。

正如上文所说，进程模型使得 PostgreSQL 可以将不同的服务分配给多个进程独立运行，每个进程负责不同的任务，例如查询处理、并发控制、锁管理等。进程模型还可以可以保证系统的稳定性和可靠性。当一个进程出现问题时，不会影响到其他进程的正常运行，从而提高了系统的可用性。

这样的特点使得 PostgreSQL 可以同时处理大量的并发请求，提高了系统的性能和响应速度；除此之外，PostgreSQL 还可以很容易地进行水平扩展，增加更多的节点以应对更高的负载。不过与此同时，也让 PostgreSQL 面对着管理和维护成本相对较高、需要较为复杂的进程间通信和协调机制、需要消耗更多的系统资源等缺点。

6 月初，Heikki Linnakangas 发布了将 PostgreSQL 转为线程模型的提案。

线程模型是一种数据库系统的架构模型，与面向进程模型类似，它是将不同的数据库服务分配给不同的线程，每个线程独立运行，相互之间通过线程间通信进行协作。线程模型在一些轻量级的数据库系统中得到广泛应用，例如 SQLite。

线程模型与进程模型的最大区别在于，线程模型中所有的线程共享同一个进程的地址空间，每个线程有自己的堆栈，共享代码段和数据段。这意味着线程之间可以直接访问同一份内存，因此线程间通信的成本相对较低，不过这也意味着线程间的数据共享可能会带来安全性问题。

从进程模型转换成线程模型的优缺点：

• 安全性问题：线程之间共享同一份内存，可能会带来安全性问题，例如数据竞争和锁竞争等。

• 可靠性问题：线程模型中一个线程崩溃可能会影响到整个进程的稳定性和可靠性。

• 多线程编程难度较大：线程之间的通信需要进行同步和互斥，编写多线程程序的难度相对较大。

PostgreSQL 开发者、EnterpriseDB 高级数据库架构师 Andres Freund 指出：

我认为原有流程模型开始产生诸多限制，这个问题在大型设备上体现得尤其明显。跨进程上下文切换所带来的开销，原本就比在同一进程内的不同线程间切换要更高 —— 我估计这种开销还将持续提升。面对大量连接，整个体系最终一定会因 TLB 未命中而浪费大量时间。这是进程模型无法跨进程共享 TLB 的天然属性造成的必然结果。

目前这还仅仅只是一项提议，并且由于 PostgreSQL 被广泛用于生产环境，转换到线程模型的过程需要非常谨慎。开发团队需要在不影响现有生产环境的情况下测试新的线程模型，以确保其稳定性和可靠性。即便这个提议通过，这个转化过程肯定也是无法通过单一版本彻底完成，从网上的各方评价来看，目前大多数人都支持这项提议。