lt_prewarm 模块提供了一种方便的方式，可以将关系数据加载到操作系统缓存或 LightDB 缓存中。可以使用
pg_prewarm 函数手动进行预热，也可以在
shared_preload_libraries 中包含 lt_prewarm
来自动执行预热。在后一种情况下，系统会运行一个后台进程，定期将共享缓存的内容记录到名为 autoprewarm.blocks 的文件中，并使用 2 个后台进程在重启后重新加载这些块。
LightDB 在启动（重启）过程中增加了自动预热的功能，包括自动预热数据库、表和索引。预热数据库时，它会预热数据库下的所有非系统表（包括表下的分区表和索引）。预热表时，它也会预热表的分区表和索引。当然，在同时配置预热数据库和数据库下的表时，我们不会重复预热。
pg_prewarm(regclass, mode text default 'buffer', fork text default 'main',
first_block int8 default null,
last_block int8 default null) RETURNS int8
第一个参数是要预热的关系。第二个参数是要使用的预热方法，如下面所讨论的；第三个参数是要预热的关系分支，通常为 main。第四个参数是要预热的第一个块号（NULL
被接受为零的同义词）。第五个参数是要预热的最后一个块号（NULL 表示预热到关系中的最后一个块）。返回值是预热的块数。
有三种可用的预热方法。 prefetch 向操作系统发出异步预取请求（如果支持的话），否则会抛出错误。 read 读取请求范围内的块；与
prefetch 不同，它是同步的，并且在所有平台和构建中都支持，但可能会更慢。 buffer 将请求范围内的块读入数据库缓存中。
注意，使用任何一种方法，尝试预热的块数超过了可以缓存的数量 — 当使用 prefetch 或 read 时，由操作系统缓存；当使用
buffer 时，由 LightDB 缓存 —
可能会导致较低编号的块被逐出，因为高编号的块被读入。预热的数据也没有受到缓存逐出的特殊保护，因此可能会发生其他系统活动在读取后不久将新预热的块逐出；相反，预热也可能从缓存中逐出其他数据。因此，通常在启动时，当缓存大部分为空时，预热最有用。
autoprewarm_start_worker() RETURNS void
启动主要的 autoprewarm 工作进程。这通常会自动发生，但如果在服务器启动时未配置自动预热，并且您希望稍后启动工作进程，则此函数很有用。
autoprewarm_dump_now() RETURNS int8
立即更新 autoprewarm.blocks。如果 autoprewarm 工作进程未运行但您预计在下次重启后运行它，则此操作可能很有用。返回值是写入
autoprewarm.blocks 的记录数。
这些参数必须在 lightdb.conf 中设置。
典型用法可能是：
# lightdb.conf shared_preload_libraries = 'pg_prewarm' pg_prewarm.autoprewarm = true pg_prewarm.autoprewarm_interval = 300s