数据库的核心功能之一是数据访问，数据访问越接近计算单元越好。然而，cpu缓存昂贵且稀缺，因此需要使用cpu的1、2、3级缓存。cpu的大部分时间用于处理这些缓存之间的信息交换。然而，这些缓存仍不足以处理所有数据，因此引入了内存。为了永久存储信息，数据被存储在磁盘上。这就是数据处理和存储的基本原理，数据库软件也基于此设计，以达到最佳性价比。
POSTGRESQL数据库的缓存需要处理数据和索引，这些信息以8KB的块存储在磁盘上，处理时需要读取到4KB的缓存单元中。此外，查询的执行计划也被存储在缓存中。
对于数据库来说，最重要的是如何快速地将数十亿数据从磁盘加载到内存中，使计算成为可能。POSTGRESQL与其他数据库不同之处在于，它依赖于LINUX的缓存，每次数据提取都从LINUX的文件缓存中获取。数据库的主要努力是让处理的数据尽可能长时间地留在内存中，同时将不再使用的数据从内存中移除。这就是LRU算法在数据库中的意义。
PG通过postmaster为每个数据库数据访问分配一个基于其子进程的进程。这些进程在访问共享缓冲区后，根据LRU算法让数据持续留在缓冲区中。当这些数据在一定时间内不再需要时，checkpoint子进程会将这些数据重新写入磁盘，释放缓冲区以接纳新数据。
实际上，缓存（这里指操作系统缓存）在PG中的意义如下：
简化PG内部缓冲与数据调用的代码，调用操作系统代码来获取数据，使系统结构变得简单。随着操作系统的升级，PG的性能可能得到提升，达到一举三得的效果。当然，如果操作系统性能不佳，则会影响结果。
通过操作系统缓存加速数据读取，如果操作系统缓存足够大，共享缓冲区的意义会减弱。
反思：随着硬件的变化，SSD的性能越来越高，价格越来越便宜。硬件的变化对PG性能提升的意义更大。在某些SSD磁盘系统上进行测试，通过预加载数据对性能的提高有限。
我们进行一个实验，比较数据在内存中和不在内存中查询的差异（以下实验在传统SATA磁盘系统上）。
我们向PG数据库中灌入5000万条数据。通过语句可以查出表在内存中的数据块数量。
我们通过命令将数据库中people_warm的缓存从共享缓冲区中清空。
我们通过简单查询5000万条数据，花费了26秒。
此时，一部分数据已经进入缓存。
我们再次清空数据。通过pg_prewarm将数据加载进缓存中。
可以看到，这次查询仅需2秒。
执行计划没有变化。这证明了数据在缓冲区中和不在缓冲区中的巨大差异。
pg_prewarm有三种模式：
Prefetch：将数据迁移至LINUX系统的操作系统缓存，而不是PG的缓冲区，数据加载方式为异步。
Read：读取所有数据加载到LINUX缓存中。
Buffer：读取所有数据块到PG的共享缓冲区中。
下图展示了几个工具和参数在数据引入内存的深度问题上的不同。
通过工具的使用，我们也能了解到postgresql本身的数据读取必须通过LINUX的缓存，也称为操作系统缓存。
另一个问题是PG的共享缓冲区与系统剩余内存容量之间的关系。之前官方的调整参数建议是1/4共享缓冲区，3/4LINUX操作系统。
我们通过一个测试来看看是否如此。
这里有一个4核，8G内存，SSD磁盘系统的系统，并且通过pgbench生成一个5000万的表。然后我们通过改变共享缓冲区的情况，观察数据库性能与共享缓冲区变化的关系。
pgbench -i --unlogged-tables -s 500 -U postgres -p 5432 -d pgbench
之前写的一篇与此相关的文章：
PostgreSQL 自己的 DB buffer & 与别的人的OS cache 之 回答问题https://cloud.tencent.com/developer/article/1536270
通过一个简单的测试，我们将共享缓冲区设置成不同的数值，然后观察每条SQL的平均延迟，以及30秒内运行的事务总数。当然，以下的测试并不严谨，严谨的测试需要在时间、客户端数量以及测试数据等方面进行更多的数据测试，并且每个测试至少要测试10次，并取平均数。
由于时间有限，以下测试结果仅供参考，根据结果：
共享缓冲区可以设置超过总物理内存的大小，系统不会报错。
这里3G，占总内存的37.5%的结果是最好的，而不是2G根据官方的建议，我们这里应该设置成2G。
虽然2G不是最好的成绩，但在9次测试中是较好的成绩。
最差的成绩是将所有的内存都设置成共享缓冲区。
将共享缓冲区设置成9G并不是这些成绩中最差的，比5G和4G的成绩要好。
当然，以上的测试并不能说明我们最好将内存设置为总体内存的37.5%，但我们需要思考，并且有时候需要问自己一个问题：
为什么官方的建议是0.25？
原因是什么？
