ruby-on-rails - 升级到 Rails 7 后 Active Record 类型映射查询的性能问题

Question

TL;DR

The intent of this commit on Active Record was to make the initial type map query less expensive but after upgrading from rails 6.1.7 to 7.0.4 this query is taking way longer than its previous version and I can't figure out why.

编辑

正如 jjanes 在下面的回答中所建议的那样，升级到 PostgreSQL 14 解决了这个问题。

升级后执行时间从 9656.222 毫秒减少到 60.618 毫秒

---

在升级到 rails 7.0.4(之前使用的是 6.1.7)之后，我们遇到了一些性能问题Amazon RDS 上的 Postgresql 实例。部署后，CPU 使用率达到 100%，实例宕机。

查看数据库日志，我看到了很多类型映射查询的发生，当一个创建与数据库的新连接。

我们的 log_min_duration_statement 设置为 10000，因此它会记录任何超过 10 秒的语句。

在 rails 升级之前，我每天看到几次类型映射查询，平均持续时间为 11 秒。升级后，我看到它的持续时间在 13 秒到 90 秒之间变化。

我将这两个查询放在要点中，结果为 EXPLAIN (ANALYZE, BUFFERS):

• rails 7
• rails 6 (pre-update)

我注意到这个提交将类型映射查询更改为更便宜，但它在我们的应用程序中做了相反的事情。

问题似乎出在 query_conditions_for_known_type_types 方法生成的语句上

目前我们正在使用:

• rails 7.0.4(升级形式 6.1.7)
• ruby 3​​.1.2
• Amazon RDS 上的 PostgreSQL 13.7
• Multi-Tenancy 数据库，其中每个租户在单个数据库中都有自己的架构。 (大约 2000 个模式)
• ros-公寓 gem
• 有 20 个线程和外部执行模式的 good_job

对于我们为何在此查询中看到此性能问题有任何想法吗？

Answer 1

在 PostgreSQL v14 之前，针对大量常量列表的 IN 列表没有针对哈希表查找进行优化。因此，这个查询在 v13 中很糟糕也就不足为奇了。

我不知道他们是否没有针对旧版本的 PostgreSQL 测试此 ROR 更改，或者没有使用与您一样大的 pg_type 表或与您一样长的 IN-list 进行测试，或者其他什么。我对 ROR 了解不多，我只是在看 PostgreSQL 方面的事情

我最初的模拟没有重现这个问题，因为我假设 pg_type 表的大小与 IN-list 的大小大致相同，但显然这是一个错误的假设，如 Rows 所示被 Filter: 行删除。

假设您不能/不想撤销此 ROR 更改，也许最简单的解决方案是迁移到 PostgreSQL v14。