將PostreSQL從9.1升級到9.4後性能下降

Question

將Postgres 9.1升級到9.4後，性能變得非常低下。以下是兩個查詢運行速度顯着更慢的示例。

注意：我意識到這些查詢可能會被重寫爲更有效的工作，但我關心的主要問題是升級到更新版本的Postgres後，它們突然以更慢的速度運行100倍！我希望有一個我忽略的配置變量。

在升級過程中，我使用了pg_upgrade命令和--link選項。配置文件在9.4和9.1之間相同。它不是在完全相同的硬件上運行的，但它們都在Linode上運行，並且我已經嘗試使用3種不同的Linode來作爲新服務器，所以我不認爲這是硬件問題。

看起來在這兩種情況下，9.4是使用不同的索引比9.1？

9.1：

EXPLAIN ANALYZE SELECT "id", "title", "timestamp", "parent", "deleted", "sunk", "closed", "sticky", "lastupdate", "views", "oldid", "editedon", "devpost", "hideblue", "totalvotes", "statustag", "forum_category_id", "account_id" FROM "forum_posts" WHERE "parent" = 882269 ORDER BY "timestamp" DESC LIMIT 1; 
                     QUERY PLAN                  
    ----------------------------------------------------------------------------------------------------------------------------------------------------- 
    Limit (cost=63.87..63.87 rows=1 width=78) (actual time=0.020..0.020 rows=0 loops=1) 
     -> Sort (cost=63.87..63.98 rows=45 width=78) (actual time=0.018..0.018 rows=0 loops=1) 
      Sort Key: "timestamp" 
      Sort Method: quicksort Memory: 17kB 
      -> Index Scan using index_forum_posts_parent on forum_posts (cost=0.00..63.65 rows=45 width=78) (actual time=0.013..0.013 rows=0 loops=1) 
        Index Cond: (parent = 882269) 
    Total runtime: 0.074 ms 
    (7 rows) 

9.4：

EXPLAIN ANALYZE SELECT "id", "title", "timestamp", "parent", "deleted", "sunk", "closed", "sticky", "lastupdate", "views", "oldid", "editedon", "devpost", "hideblue", "totalvotes", "statustag", "forum_category_id", "account_id" FROM "forum_posts" WHERE "parent" = 882269 ORDER BY "timestamp" DESC LIMIT 1; 
                       QUERY PLAN                    
----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=0.42..63.48 rows=1 width=1078) (actual time=920.484..920.484 rows=0 loops=1) 
    -> Index Scan Backward using forum_posts_timestamp_index on forum_posts (cost=0.42..182622.07 rows=2896 width=1078) (actual time=920.480..920.480 rows=0 loops=1) 
     Filter: (parent = 882269) 
     Rows Removed by Filter: 1576382 
Planning time: 0.166 ms 
Execution time: 920.521 ms 
(6 rows) 

9.1：

EXPLAIN ANALYZE SELECT "user_library_images"."id", "user_library_images"."imgsrc", "user_library_images"."library_image_id", "user_library_images"."type", "user_library_images"."is_user_uploaded", "user_library_images"."credit", "user_library_images"."orig_dimensions", "user_library_images"."account_id" FROM "user_library_images" INNER JOIN "image_tags" ON "user_library_images"."id" = "image_tags"."user_library_image_id" WHERE ("user_library_images"."account_id" = 769718 AND "image_tags"."tag" ILIKE '%stone%') GROUP BY "user_library_images"."id", "user_library_images"."imgsrc", "user_library_images"."library_image_id", "user_library_images"."type", "user_library_images"."is_user_uploaded", "user_library_images"."credit", "user_library_images"."orig_dimensions", "user_library_images"."account_id" ORDER BY "user_library_images"."id"; 

Group (cost=2015.46..2015.49 rows=1 width=247) (actual time=0.629..0.652 rows=6 loops=1) 
    -> Sort (cost=2015.46..2015.47 rows=1 width=247) (actual time=0.626..0.632 rows=6 loops=1) 
     Sort Key: user_library_images.id, user_library_images.imgsrc, user_library_images.library_image_id, user_library_images.type, user_library_images.is_user_uploaded, user_library_images.credit, user_library_images.orig_dimensions, user_library_images.account_id 
     Sort Method: quicksort Memory: 19kB 
     -> Nested Loop (cost=0.00..2015.45 rows=1 width=247) (actual time=0.283..0.603 rows=6 loops=1) 
       -> Index Scan using index_user_library_images_account on user_library_images (cost=0.00..445.57 rows=285 width=247) (actual time=0.076..0.273 rows=13 loops=1) 
        Index Cond: (account_id = 769718) 
       -> Index Scan using index_image_tags_user_library_image on image_tags (cost=0.00..5.50 rows=1 width=4) (actual time=0.020..0.021 rows=0 loops=13) 
        Index Cond: (user_library_image_id = user_library_images.id) 
        Filter: (tag ~~* '%stone%'::text) 
Total runtime: 0.697 ms 
(11 rows) 

9.4：

Group (cost=166708.13..166709.46 rows=59 width=1241) (actual time=9677.052..9677.052 rows=0 loops=1) 
    Group Key: user_library_images.id, user_library_images.imgsrc, user_library_images.library_image_id, user_library_images.type, user_library_images.is_user_uploaded, user_library_images.credit, user_library_images.orig_dimensions, user_library_images.account_id 
    -> Sort (cost=166708.13..166708.28 rows=59 width=1241) (actual time=9677.049..9677.049 rows=0 loops=1) 
     Sort Key: user_library_images.id, user_library_images.imgsrc, user_library_images.library_image_id, user_library_images.type, user_library_images.is_user_uploaded, user_library_images.credit, user_library_images.orig_dimensions, user_library_images.account_id 
     Sort Method: quicksort Memory: 17kB 
     -> Hash Join (cost=10113.22..166706.39 rows=59 width=1241) (actual time=9677.035..9677.035 rows=0 loops=1) 
       Hash Cond: (image_tags.user_library_image_id = user_library_images.id) 
       -> Seq Scan on image_tags (cost=0.00..156488.85 rows=11855 width=4) (actual time=0.301..9592.048 rows=63868 loops=1) 
        Filter: (tag ~~* '%stone%'::text) 
        Rows Removed by Filter: 9370406 
       -> Hash (cost=10045.97..10045.97 rows=5380 width=1241) (actual time=0.047..0.047 rows=4 loops=1) 
        Buckets: 1024 Batches: 1 Memory Usage: 1kB 
        -> Bitmap Heap Scan on user_library_images (cost=288.12..10045.97 rows=5380 width=1241) (actual time=0.027..0.037 rows=4 loops=1) 
          Recheck Cond: (account_id = 769718) 
          Heap Blocks: exact=4 
          -> Bitmap Index Scan on index_user_library_images_account (cost=0.00..286.78 rows=5380 width=0) (actual time=0.019..0.019 rows=4 loops=1) 
           Index Cond: (account_id = 769718) 
Planning time: 0.223 ms 
Execution time: 9677.109 ms 
(19 rows) 

====

運行分析腳本（請參閱下面的答案）後，問題就解決了。作爲參考，這裏是新的ANALYZE輸出（9.4）：

Group (cost=2062.82..2062.91 rows=4 width=248) (actual time=8.775..8.801 rows=7 loops=1) 
    Group Key: user_library_images.id, user_library_images.imgsrc, user_library_images.library_image_id, user_library_images.type, user_library_images.is_user_uploaded, user_library_images.credit, user_library_images.orig_dimensions, user_library_images.account_id 
    -> Sort (cost=2062.82..2062.83 rows=4 width=248) (actual time=8.771..8.780 rows=7 loops=1) 
     Sort Key: user_library_images.id, user_library_images.imgsrc, user_library_images.library_image_id, user_library_images.type, user_library_images.is_user_uploaded, user_library_images.credit, user_library_images.orig_dimensions, user_library_images.account_id 
     Sort Method: quicksort Memory: 19kB 
     -> Nested Loop (cost=0.87..2062.78 rows=4 width=248) (actual time=4.156..8.685 rows=7 loops=1) 
       -> Index Scan using index_user_library_images_account on user_library_images (cost=0.43..469.62 rows=304 width=248) (actual time=0.319..2.528 rows=363 loops=1) 
        Index Cond: (account_id = 769718) 
       -> Index Scan using index_image_tags_user_library_image on image_tags (cost=0.43..5.23 rows=1 width=4) (actual time=0.014..0.014 rows=0 loops=363) 
        Index Cond: (user_library_image_id = user_library_images.id) 
        Filter: (tag ~~* '%stone%'::text) 
        Rows Removed by Filter: 2 
Planning time: 2.956 ms 
Execution time: 8.907 ms 
(14 rows) 



Limit (cost=65.81..65.81 rows=1 width=77) (actual time=0.256..0.256 rows=0 loops=1) 
    -> Sort (cost=65.81..65.92 rows=47 width=77) (actual time=0.252..0.252 rows=0 loops=1) 
     Sort Key: "timestamp" 
     Sort Method: quicksort Memory: 17kB 
     -> Index Scan using index_forum_posts_parent on forum_posts (cost=0.43..65.57 rows=47 width=77) (actual time=0.211..0.211 rows=0 loops=1) 
       Index Cond: (parent = 882269) 
Planning time: 2.978 ms 
Execution time: 0.380 ms 
(8 rows) 

Answer 1

pg_upgrade不會複製（或遷移）的統計數據爲你的數據庫。

因此，您需要分析您的表以便更新遷移數據庫中的統計信息。 pg_upgrade將創建一個名稱爲analyze_new_cluster的批處理文件/ shell腳本，可用於此目的。

或者，您可以手動使用vacuum analyze來實現相同的目的。

通過查看執行計劃可以檢測到缺少的統計信息。行的預期數目和實際的號之間的差是太高：

(cost=0.00..286.78 rows=5380 width=0) (actual time=0.019..0.019 rows=4 loops=1) 

==> 5380對4行

或

(cost=0.00..156488.85 rows=11855 width=4) (actual time=0.301..9592.048 rows=63868 loops=1) 

==> 11855與63868行