當我創建了太多的分區時，PostgreSQL的性能下降很糟糕

我不明白爲什麼當我爲表創建太多的分區時，postgreSQL中的性能下降。當我創建了太多的分區時，PostgreSQL的性能下降很糟糕

100 - > 0.05秒
200 - > 0.07秒
400 - > 0.16秒
600 - > 0.24秒
800 - > 0.29秒
1000 - > 0.37 sec
1,500→0.62秒
2,000→0.82秒
4000 - > 1.86秒
10,000 - > 7.62秒

下面是測試查詢和解釋的結果。

select count(*) from test_sql_stat_daily 
where partition_key=1000000099; 

Aggregate (cost=20000000011.88..20000000011.89 rows=1 width=0)" 
    Output: count(*)" 
    -> Append (cost=10000000000.00..20000000011.88 rows=2 width=0)" 
     -> Seq Scan on test_sql_stat_daily (cost=10000000000.00..10000000000.00 rows=1 width=0)" 
       Filter: (test_sql_stat_daily.partition_key = 1000000099)" 
     -> Seq Scan on test_sql_stat_daily_p0000000099 test_sql_stat_daily (cost=10000000000.00..10000000011.88 rows=1 width=0)" 
       Filter: (test_sql_stat_daily.partition_key = 1000000099)"

我想克服這種情況。對這種情況沒有影響。

增加共享緩衝器
的大小創建主鍵約束指數（和創建索引），用於CHECK約束柱
組constraint_exclusion =上

來源

2014-10-17 seankim

我upvoted！我知道分區太多時性能下降，但從來沒有打擾過測試自己。我傾向於認爲，張貼的數字顯示大部分計劃時間（根據'rows = 1'估計值來判斷）。嚇唬年輕的DBA是一件好事：「嘿，在空桌子上有10k分區會讓你的查詢運行時間不會少於7秒！」:) – vyegorov 2014-10-17 06:47:57

這個問題看起來是無關緊要的，因爲它是關於創建一個瘋狂的分區數量。 – 2014-10-21 21:47:21

的documented approach是「不要去做。」

在主表的所有分區的所有限制約束排除過程中進行檢查，所以大量的分區有可能增加查詢規劃的時間相當。使用這些技術進行分區將可能適用於多達100個分區; 不要嘗試使用數千個分區。

強調增加。

如果我是你，我會嘗試將分區數降至1000。

來源

2014-10-17 04:33:04

當我創建了太多的分區時，PostgreSQL的性能下降很糟糕

回答

相關問題