AWS Aurora PostgreSQL Serverless：您如何在扩展后预热共享缓冲区？

Question

我正在使用AWS Aurora PostgreSQL Serverless自动缩放。看起来好像缩放清除了共享缓冲区，所以当我们想要提高性能时，我们被迫面对 I/O 瓶颈。在我们热身之后，我们看到了巨大的性能提升。但是，如果我们在缩放后背靠背运行，则第二次运行会更快。虽然我没有看到任何关于共享缓冲区是否在缩放时被清除的具体信息，但我几乎肯定它是。

Aurora Serverless 目前正在使用PostgreSQL 10.14，并且支持pg_prewarm扩展。它看起来像最新的文件显示在服务器重新启动后prewarm支持自动prewarm，但这是无服务器并不会出现提自动预暖的一个版本的文档中。

我发现这篇文章在重新启动服务器或从崩溃中恢复时非常适合 PostgreSQL。

1. 如果我们至少可以在缩放后保留下 ACU 节点的共享缓冲区的内容，那就没问题了。
2. 如果我们可以提前预热需要在内存中的内容，那就太棒了！
3. 有些桌子非常大，我们希望有选择地预热我们想要的作品。 pg_prewarm支持first_block和last_block阻止表/索引的编号，但是如何知道要放入哪些值呢？

我们提前知道我们的峰值是什么时候，并告诉 RDS 在此之前进行扩展，因此我们有一个可以准备的时间窗口。

我有哪些选择？

Answer 1

_{我的回答并不是针对 AWS Aurora PostgreSQL Serverless，而是针对一般的 Postgres。}

简单的选择

在您的相关评论中，您暗示您只需要过去 24 小时的行。所以你可以（不涉及 pg_prewarm）简单地：

SELECT * FROM public.tbl WHERE created_at > now() - interval '24h';

如果created_at被索引，并且谓词有足够的选择性，则对表和索引的相关块进行预热。

由于您实际上不想在预热时检索任何数据，因此可以PERFORM在DO语句中使用：

DO
$$BEGIN
   PERFORM * FROM public.tbl WHERE created_at > now() - interval '24h';
END$$;

一样的效果。
您可以通过以下方式验证成功EXPLAIN (ANALYZE, BUFFERS)：

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM public.tbl WHERE created_at > now() - interval '24h';

如果有足够的缓存可用，您现在应该只能看到“共享命中”缓冲区。喜欢：

Buffers: shared hit=123456

.. 在那里你会看到主要是“读取”，主要是冷缓存。喜欢：

Buffers: shared hit=143 read=153689

基本上，只需运行预期的查询，缓存就会相应地填充。

pg_prewarm()

如果您仍想使用pg_prewarm()块编号，也可以这样做。允许更多选项，例如选择要填充的缓存（操作系统或数据库缓冲区缓存）或其他一些技巧。必须首先安装附加模块，每个数据库一次：

CREATE EXTENSION pg_prewarm;

仅当您的表（大部分）物理上聚集在假定的 column 上时，处理块编号才有意义created_at。只读（主要是读取）表就是这种情况，其中具有当前时间戳的新行附加在表的末尾。

您可以从其ctid. 看：

• 如何将ctid分解为页码和行号？

要获取小于 24 小时的第一行的块号：

SELECT ctid
FROM   public.tbl
WHERE  created_at > now() - interval '24h'
ORDER  BY created_at
LIMIT  1;

你会得到类似的东西(5759,1)。5759是块号。然后你可以：

SELECT pg_prewarm('public.tbl'::regclass, first_block => 5759)

由于我们保留last_block了默认值NULL，因此“通过关系中的最后一个块”的所有内容都将被预热。（不过不是索引。你也可以预热它。）

函数调用使用“混合符号”（“位置”和“命名符号”的混合）。看：

• 具有可变数量输入参数的函数