哪些因素会导致“选择 1”的规划时间变慢？

Question

我有一个由生产应用程序使用的数据库。它是 Amazon RDS 上的 db.m3.medium。我们注意到，许多查询开始变慢，而通常情况下不应变慢（例如按主键选择行）。

我们开始调查这个问题，发现我们select 1对数据库的健康检查也很慢。例如，以下是explain (analyze buffers) select 1大约 20 小时内每秒运行的一些图表：

持续时间（往返时间）（毫秒）

我将 y 轴的上限设置为 500 毫秒。

规划（毫秒）

我将 y 轴的上限设置为 100 毫秒。

执行（毫秒）

我将 y 轴的上限设置为 100 毫秒。

---

计划一个查询要花费如此极端的时间，这似乎很疯狂。

当我们从整体上查看数据库时，似乎没有任何迹象表明它承受着足够重的负载。这是典型的一天：

中央处理器

读取（蓝色）/写入（紫色）吞吐量 (MiB/s)

网络传输（紫色）/接收（蓝色）吞吐量（KiB/s）

磁盘

磁盘大小为 30 GiB，已使用 5.75 GiB。

记忆

有 3.75 GiB 的 RAM，还有 2.2 GiB 是免费的。

---

该数据库实例是自 2017 年 12 月 17 日起的新实例（由于需要 AWS 维护而从另一个实例进行手动故障转移之后）。我们的假设是单核导致操作系统（和 Postgres）出现上下文切换问题。然而，数据库的任何指标都没有真正表明它运行得非常热。我还可以确认我们没有任何长时间运行的查询/交易。

什么可能导致简单查询（例如select 1规划和执行时间较长）？