我有一个相当大的（~10M 行）表，最近开始放慢速度。作为解决方案，我们决定将该表划分为 1,000 个表，按客户端 ID 的哈希进行分区。这样，我们通常每个表只有几个客户端。我们在生产中与现有表一起创建了这个分区，并填充了所有数据，并使它们与触发器函数保持同步。对分区表手动运行查询显示出巨大的希望，大多数人看到 10-100 倍以上的加速。认为一切都很好，我们在生产环境中交换了两个表名，它立即使我们的数据库崩溃。
- 可释放内存立即从 6 GB 降至 0
- 交换使用量从 0 GB 跃升至 3 GB
- 数据库变慢了，以至于我们不得不完全关闭网络应用程序，因此没有与数据库的连接并恢复表名交换。
我已经完成了使用该表的查询，并且所有查询都有一个明确的WHERE client_id = <client_id>，因此他们应该只使用他们的分区而不是父表。他们都没有选择跨多个分区。
什么可能使用这么多内存？Postgres 分区有那么多内存开销吗？根据我的阅读，Postgres 应该能够处理数万个分区，所以我的 1,000 个应该不是问题。
这一切都在具有 4 个 vCPU 和 16 GB RAM 的 RDS M5.xlarge 实例上。
更新： 我们将实例大小升级为具有 32 GB RAM 的实例，并将分区数量从 1,000 个缩减到仅 250 个，然后再次尝试。这次我们看到内存立即下降，但在趋于平稳之前只有大约 3-4 GB，这表明内存随着分区数量的增加而扩展。同样，在交换表名之前，我们已经通过触发器对分区执行了大量的 INSERT/UPDATE/DELETE 命令，并且没有看到明显的影响。只有当表名被交换以便 SELECT 开始命中它时，我们才看到内存的巨大下降。这似乎与说明内存命中对于 UPDATE 和 DELETE 命令特别糟糕的文档不一致。