Postgres中有多少個表分區太多？

我正在對包含時態數據的非常大的表進行分區，並考慮應該使分區達到什麼粒度。 Postgres partition documentation聲稱「大量的分區可能會大大增加查詢計劃時間」，並建議將分區與「高達大約一百個」分區一起使用。Postgres中有多少個表分區太多？

假設我的表格包含十年的數據，如果按星期劃分，我最終會有超過500個分區。在我排除此問題之前，我想更好地瞭解分區數量對查詢計劃時間的影響。有沒有人對此進行過基準測試，或者是否有人瞭解這是如何在內部工作的？

來源

2011-05-24 DNS

我不能評論Postgres，但不會每月分區更有意義嗎？ – 2011-05-24 01:17:40

他們幾乎肯定會;我每週都會選擇一個更實際的數字。人們可以考慮20年以上的每月分區。我主要對約束感興趣，以及它們之間有什麼區別，即50個Vs. 100個分區。 – DNS 2011-05-24 01:42:35

基於每個分區的行數，RBDMS經常存在「經驗法則」。對於SQL服務器，它大約有2000萬行 – 2011-05-24 01:50:03

的查詢規劃必須做的查詢中使用的表的每個分區的約束信息的線性搜索，找出哪些實際參與 - 具有所需的請求的數據行的人。計劃者考慮的查詢計劃數隨着您加入更多表而呈指數增長。因此，線性搜索加起來足夠麻煩的確切時間取決於查詢的複雜性。聯接越多，就越會受到這個影響。「高達一百」的數字來自於指出查詢規劃時間即使在圍繞該點的簡單查詢中也增加了不少的時間。特別是在Web應用程序中，響應時間延遲很重要，這是一個問題;從而警告。

你能支持500嗎？當然。但是您將搜索每個涉及該優化器考慮的表的每個查詢計劃的500個檢查約束中的每一個。如果查詢計劃時間不是您關心的問題，那麼也許您不在乎。但是大多數網站最終不喜歡花費在用多個分區進行查詢計劃上的時間比例，這就是爲什麼每月分區是大多數數據集標準的原因之一。您可以輕鬆存儲10年的數據，每月進行分區，然後再開始進入計劃開銷明顯的地方。

來源

2011-05-25 21:54:03

如果您不想信任編寫代碼的PostgreSQL開發人員，那麼我建議您自己親自嘗試一下，並運行一些示例查詢，並使用不同的分區方案對其進行解釋分析和計時。任何情況下，您的特定硬件和軟件配置都可能主導任何答案。

我假設查詢優化器用來確定要使用的連接和限制的行優化緩存與每個分區一起存儲，因此它可能需要加載和讀取每個分區的部分來計劃查詢。

來源

2011-05-24 03:17:22

我相信開發者，但他們的警告非常模糊，所以我想更好地理解它。我的問題，就像大多數Stack Overflow一樣，被問到如果有人已經知道答案，我不必花費數小時建立一個代表性的測試設置來重現他們的工作。 – DNS 2011-05-24 03:42:40

@DNS它很模糊，因爲它取決於您的硬件和軟件配置，數據和查詢。一個人適合的答案不適合另一個人。 SQL很微妙。 – 2011-05-24 03:57:46

每個表分區在文件系統上佔用一個inode。「非常大」是一個相對術語，取決於您選擇的文件系統的性能特徵。如果你想要明確的性能基準，你可以從操作系統和FS選擇的郵件系統的各種性能基準。一般來說，我不會擔心它，直到你進入成千上萬到數十萬個表空間（在FreeBSD的UFS2上使用dirhash會獲勝）。還要注意，這個相同的限制適用於PostgreSQL中的DATABASES，TABLES或任何其他文件系統支持的數據庫對象。

來源

2011-05-24 05:16:49 Sean

「大量的分區可能會大大增加查詢計劃時間」，並建議將分區與「最多一百個」分區一起使用。

因爲每個額外的分區通常都與檢查約束有關，這將導致規劃者想知道哪些分區需要查詢。在最好的情況下，計劃者會發現你只打到一個分區，並且完全擺脫了步驟append。

行的方面，並作爲DNS和賽斯指出，你milage將與硬件的不同而不同。一般來說，雖然，有查詢1M行的表和一個10M行的表之間沒有顯著差異 - 使用你最該指數特別是如果你的硬盤驅動器允許快速隨機訪問，如果它的集羣（見cluster語句）經常打。

來源

2011-05-24 06:08:46

Postgres中有多少個表分區太多？

回答

相關問題