postgresql - 9.6 升级后 postgresql IN 查询出现奇怪的性能问题

Question

我们有一个数据库当前在 Postgresql 9.5.4 上的 AWS RDS 中运行，我们正在尝试将其升级以运行 9.6.6。升级后我们遇到了奇怪的性能下降，即使在(我们认为)成功地将所有 postgres 设置复制到 RDS 参数组之后，下面的查询似乎是一个“确凿的证据”，尽管我们没有真的明白了。

在我们的 9.5.4 实例上，以下查询都运行得很快(正如您所期望的，假设 uuid 和 account_id 列已编入索引):

production=> \timing 
Timing is on.
production=> SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1;
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 3.015 ms
production=> SELECT uuid FROM address WHERE uuid IN ('4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0');
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 0.886 ms
production=>  SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 2.431 ms

一旦我们将该数据库升级到 9.6.6，前两个查询仍然很快，但最后一个变得非常慢:

production=> \timing 
Timing is on.
production=> SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1;
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 0.732 ms
production=> SELECT uuid FROM address WHERE uuid IN ('747b4b38-81f3-487e-8202-06c964e7e9f8');
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 0.715 ms
production=> SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 6676.759 ms

在 9.6.6 框上，查询规划器没有提供任何提示(至少，我可以看到):

production=> EXPLAIN SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                                                                   QUERY PLAN                                                                    
-------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=5.23..13.27 rows=1 width=16)
   ->  HashAggregate  (cost=4.67..4.68 rows=1 width=16)
         Group Key: address_1.uuid
         ->  Limit  (cost=0.56..4.66 rows=1 width=16)
               ->  Index Scan using address_account_id on address address_1  (cost=0.56..725.46 rows=177 width=16)
                     Index Cond: ((account_id)::text = 'Demo'::text)
   ->  Index Only Scan using address_pkey1 on address  (cost=0.56..8.58 rows=1 width=16)
         Index Cond: (uuid = address_1.uuid)
(8 rows)

此外，在两个盒子上运行标准的 pgbench 测试实际上表明 9.6.6 盒子在每秒事务处理方面优于 9.5.4 盒子，所以我不认为有什么奇怪的那里发生的硬件问题。

想知道是否有人对第三个查询的性能奇怪下降可能来自何处有任何想法？

Answer 1

原来这是因为在 9.5 -> 9.6 升级后，您需要ANALYZE 整个数据库才能让查询规划器再次运行。