PostgreSQL配置pg_prewarm预加热缓冲区，删表重建后调用返回0

先澄清对返回值的核心误解 #

pg_prewarm() 从来就不是用返回值标记操作成功或失败的函数。它的实际输出是：本次执行过程中，从磁盘成功加载进PostgreSQL共享缓冲区的目标关系磁盘块总数量。
你第一次执行返回1，只是当时的旧表刚好有1个未纳入缓冲区的有效存储块，并非代表“返回1就是配置正常、返回0就是出故障”。

重建同名表后返回0是完全符合扩展设计逻辑的正常表现，最常见的触发原因有三个：

• 新建的同名表没有写入任何有效数据：PostgreSQL的堆表不会在创建时就预分配磁盘存储块，只有第一次写入数据时才会在磁盘上生成对应的实体文件。空表的磁盘占用为0，没有可加载的存储块，执行预加热自然返回0。
• 新表的所有存储块已经被自动加载到共享缓冲区：pg_prewarm不会重复加载已经存在于共享缓冲区的块，也不会对已加载的块做重复计数。你在重建表、插入测试数据、执行日常查询的过程中，PostgreSQL本身就会自动把访问过的块加载进缓冲区，等你手动执行预加热命令时，根本找不到还没进缓冲区的块，自然计数为0。
• 新表的实际存储块数极少：如果重建后的表只有1个甚至几个块，日常操作下这些块会第一时间被纳入缓冲区，根本轮不到手动预加热去加载，返回0是必然结果。

快速验证是否为正常表现 #

按照以下步骤排查即可确认是否存在配置或操作疏漏，全程不需要调整原有环境参数：

1. 确认扩展加载状态：执行SHOW shared_preload_libraries;，返回结果中包含pg_prewarm即代表扩展加载正确。如果扩展没有正常加载，执行预加热命令时会直接抛出“函数不存在”的错误，不会静默返回0。
2. 检查新表的实际磁盘块总量：执行

   SELECT pg_relation_size('useraccount') / current_setting('block_size')::int AS total_disk_blocks;
   

   如果返回值为0，说明表是空的没有有效数据，插入业务数据后再测试即可。
3. 排除缓冲区已有数据的干扰：如果持有超级用户权限，可以执行SELECT pg_drop_caches();清理所有非活跃的共享缓冲区块，再重新执行SELECT pg_prewarm('useraccount');。如果返回的数值和刚才查到的总块数接近，就说明你的配置、操作完全没有问题，之前返回0只是因为目标块本来就已经在缓存中。

补充说明 #

pg_prewarm的定位是“把磁盘上的冷块提前加载进共享缓冲区减少首次查询的IO开销”，它的返回值只统计本次操作新增加载的块数——已经在缓存里的块、表结构本身的元数据块、没有实体存储的空表块，都不会被计入统计，和操作是否成功没有直接关联。

内容的提问来源于stack exchange，提问作者sudoExclamationExclamation