問題

我有一個表,其中包含3個欄位(使用者名稱,target_value,分數),由完整的使用者名稱(~400,000)和target_value(~4000)生成,並計算得分,導致總行數約16億.

我在此表上的所有查詢將採用格式

 SELECT *
FROM _table
WHERE target_values IN (123, 456)
 

我的初始版本包括一個關於target_values的BTREE索引,但我最終在索引的點陣圖HEAP SCAN上花費了45分鐘. 我也一直在檢視Brin索引,分割槽和表聚類,但由於將每個方法應用於表需要幾個小時,我無法完全強制每個選項並測試效能.

postgresql – 處理Postgres 10中非常“blocky”資料的單個大量表有什麼建議?

  最佳答案

如果表是兩個資料集的交叉連線,為什麼不儲存單個表並根據需要計算連線?資料庫很好.

根據您的描述,如果您在表上執行CLUSTER按索引順序進行物理重寫,我會期望效能增加.然後您必須訪問更少的表塊.

不幸的是,CLUSTER將需要很長時間,使表不可用並且必須定期重複.

可能更好的替代方法是透過target_value分割槽表. 4000個分割槽有點多,所以可能使用列表分割槽將幾個分割槽繫結到一個分割槽中.

這將允許您的查詢只在幾個分割槽上執行快速順序掃描,這也將使自動真空的工作更容易。

然而,底線是,如果您從表中選擇許多行,那麼它總是需要很長時間。

  相同標籤的其他問題

databasepostgresqlindexingdatabase-partitioning