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整个数据库才能使查询计划程序再次嗡嗡作响。

9.6升级后，postgresql IN查询上的性能问题很奇怪

1 个答案: