PostgreSQL單列索引與多列索引優化SELECT性能

我是PostgreSQL的新手，特別是其性能調優方面。基本上我們有通過查詢3個整數值來訪問的數據：segmentSize（範圍1 ... 10），segmentX（範圍+/- 100,000），segmentY（範圍+/- 100,000）。PostgreSQL單列索引與多列索引優化SELECT性能

一個前瞻性的考慮：當數據量增長時，可能會將數據分割成多個表格，每個segmentSize和/或segmentX和segmentY的連續範圍。

目前的選擇：我有一個直接使用鍵（segmentSize，segmentX，segmentY）或 - 爲了獲得性能的架構選擇 - 在PostgreSQL之外創建一個合成關鍵字，將segmentX，segmentY合併爲一個整數價值成爲關鍵（或者不太可能，所有三個（segmentSize，segmentX，segmentY）。

問題：假設我們不太在意從segmentX派生出這個「組合鍵」的成本，segmentY發生了在Postgress之外，並且由於我們並不是專門在每行數據的字節順序上節省空間（除非它使性能有所不同）， ....將會有任何可測量或有意義的性能增益從查詢罪gle範圍segmentX * segmentY的int值，而不是查詢segmentX和segmentY的兩個單獨int值的組合。

很多很多，謝謝。請隨意添加任何擴展適用數據和索引策略的鏈接，以最大限度地提高SELECT /讀取性能。

來源

2012-04-04 SashaK

在您的查詢中使用EXPLAIN和EXPLAIN ANALYZE查看和衡量發生了什麼以及哪些效果最好。 – 2012-04-04 18:00:14

謝謝你，弗蘭克！ – SashaK 2012-04-04 18:22:14

首先：*自然*主鍵是什麼？第二：您的典型用法是什麼：在X或Y上或者{X，Y}或{Y，X}上進行範圍查詢？第三：查詢中的關鍵字組是否與「自然」PK中的不同？它與插入操作中的一組關鍵字不同嗎？第四：從三個關鍵字段的集合中：是否有可能配對的候選關鍵字？第五：請添加關鍵鑰匙的含義的描述。「segment_id」對我們大多數人來說並不是很有幫助。 – wildplasser 2012-04-04 18:31:45

將兩個（或三個）列組合成一個值的密鑰的性能優勢可能非常小。實際上，傷害表現爲一些用法;如果這些值在其他表中有意義，則需要通過綜合關鍵字「導航」，以防止計劃被考慮，這可能會更快。有一個可用的自然鍵時使用合成鍵往往會歸入「不成熟優化」的標題之下，並伴有所有相關風險 - 包括很可能會使事情變得更慢。

來源

2012-04-04 18:24:35 kgrittn

PostgreSQL單列索引與多列索引優化SELECT性能

回答

相關問題