PostgreSQL内核中引入了一个很有意思的插件，pg_prewarm。可以用于在系统重启时，手动加载经常访问的表到操作系统的cache或PG的shared buffer，从而减少检查系统重启对应用的影响。这个插件通过以下patch加入PG内核 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c32afe53c2e87a56e2ff930798a5588db0f7a516

pg_prewarm的开发者在设计pg_prewarm时，把它设计成一个执行单一任务的工具，尽求简单，所以我们看到的pg_prearm功能和实现都非常简单。下面我们对它进行性能实测并分析一下它的实现。

一、 基本信息

利用下面的语句可以创建此插件：

create EXTENSION pg_prewarm;

实际上，创建插件的过程只是用下面的语句创建了pg_prewarm函数。这个函数是此插件提供的唯一函数：

CREATE FUNCTION pg_prewarm(regclass,
mode text default buffer,
fork text default main,
first_block int8 default null,
last_block int8 default null)
RETURNS int8
AS MODULE_PATHNAME, pg_prewarm
LANGUAGE C

参数含义如下

• regclass：要做prewarm的表名
• mode：prewarm模式。prefetch表示异步预取到os cache；read表示同步预取；buffer表示同步读入PG的shared buffer
• fork：relation fork的类型。一般用main，其他类型有visibilitymap和fsm
• first_block & last_block：开始和结束块号。表的first_block=0，last_block可通过pg_class的relpages字段获得
• RETURNS int8：函数返回pg_prewarm处理的block数目（整型）

 

二、 性能实测

再来看看prewarm性能上能达到多大效果。将PG的shared buffer设为2G，OS内存7G。然后创建个大小近1G的表test：

pgbench=#  SELECT pg_size_pretty(pg_total_relation_size(test));
pg_size_pretty
----------------
995 MB

在每次都清掉操作系统cache和PG的shared buffer的情况下，分别测试下面几种场景：

1）不进行pg_prewarm

pgbench=# explain analyze select count(*) from test;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=377389.91..377389.92 rows=1 width=0) (actual time=22270.304..22270.304 rows=1 loops=1)
->  Seq Scan on test  (cost=0.00..327389.73 rows=20000073 width=0) (actual time=0.699..18287.199 rows=20000002 loops=1)
Planning time: 0.134 ms
Execution time: 22270.383 ms

可以看到，近1G的表，全表扫描一遍，耗时22秒多。

2）read模式prewarm（test表的数据被同步读入os cache）

pgbench=# select pg_prewarm(test, read, main);
pg_prewarm
------------
127389

pgbench=# explain analyze select count(*) from test;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=377389.90..377389.91 rows=1 width=0) (actual time=8577.767..8577.767 rows=1 loops=1)
->  Seq Scan on test  (cost=0.00..327389.72 rows=20000072 width=0) (actual time=0.086..4716.444 rows=20000002 loops=1)
Planning time: 0.049 ms
Execution time: 8577.831 ms

时间降至8秒多！这时反复执行全表扫描，时间稳定在8秒多（但cost没有降低）。

3）buffer模式prewarm（同步读入PG的shared buffer）

pgbench=# select pg_prewarm(test, buffer, main);
pg_prewarm
------------
127389

pgbench=# explain analyze select count(*) from test;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=377389.90..377389.91 rows=1 width=0) (actual time=8214.277..8214.277 rows=1 loops=1)
->  Seq Scan on test  (cost=0.00..327389.72 rows=20000072 width=0) (actual time=0.015..4250.300 rows=20000002 loops=1)
Planning time: 0.049 ms
Execution time: 8214.340 ms

比read模式时间略少，但相差不大。可见如果os cache够大，数据取到OS cache还是shared buffer对执行时间影响不大（在不考虑其他应用影响PG的情况下）。

4）prefetch模式

这里我们有意在pg_prewarm返回后，立即执行全表查询。这样在执行全表查询时，可能之前的预取还没完成，从而使全表查询和预取并发进行，缩短了总的响应时间。

explain analyze select pg_prewarm(test, prefetch, main);
QUERY PLAN
------------------------------------------------------------------------------------------
Result  (cost=0.00..0.01 rows=1 width=0) (actual time=1011.338..1011.339 rows=1 loops=1)
Planning time: 0.124 ms
Execution time: 1011.402 ms

explain analyze select count(*) from test;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=377389.90..377389.91 rows=1 width=0) (actual time=8420.652..8420.652 rows=1 loops=1)
->  Seq Scan on test  (cost=0.00..327389.72 rows=20000072 width=0) (actual time=0.065..4583.200 rows=20000002 loops=1)
Planning time: 0.344 ms
Execution time: 8420.723 ms

可以看到，总的完成时间也是8秒多，使用pg_prewarm做预取大大缩短了总时间。因此在进行全表扫描前，做一次异步的prewarm，不失为一种优化全表查询的方法。

 

三、 实现

pg_prewarm的代码只有一个pg_prewarm.c文件。

1. prefetch模式

对于表的每个block，调用一次PrefetchBuffer，后面的调用为：

PrefetchBuffer -> smgrprefetch  -> mdprefetch -> FilePrefetch -> posix_fadvise(POSIX_FADV_WILLNEED)

可见，它是最终调用posix_fadvise，把读请求交给操作系统，然后返回，实现的异步读取。

2. read和buffer模式

最终都调用了read，来实现同步读入OS cache和shared buffer。buffer模式实际是先读入OS cache，再拷贝到shared buffer

read模式：smgrread -> mdread -> FileRead  -> read

buffer模式：ReadBufferExtended -> ReadBuffer_common -> smgrread -> mdread -> FileRead -> read

四、 问题

可能有人比较疑惑：执行1次select * from 不就可以将表的数据读入shared buffer和OS cache而实现预热了吗？不是比做这样一个插件更简单？实际上，对于较大的表（超过shared buffer 1/4），进行全表扫描时，PG认为没必要为这种操作使用所有shared buffer，只会让其使用很少的一部分buffer，一般只有几百K，详细描述可以参见关于BAS_BULKREAD策略的代码和README）。所以，预热大表是不能用一个查询直接实现的，而pg_prewarm正是在这方面大大方便了用户。

 

参考：

http://mysql.taobao.org/monthly/2015/02/04/