正確的索引是簡單的表

我有PostgreSQL的9.1表：正確的索引是簡單的表

_id   | integer | not null default nextval('"01f9073e-e6b8-46bf-882f-9a4cd0a69a66__id_seq"'::regclass) 
_full_text | tsvector | 
tlRecordID | text  | 
tlPDM   | text  | 
tlPayDateTime | text  | 
tlExpDateTime | text  | 
Indexes: 
    "01f9073e-e6b8-46bf-882f-9a4cd0a69a66_pkey" PRIMARY KEY, btree (_id) 
    "01f9073e-e6b8-46bf-882f-9a4cd0a69a66_tlRecordID_idx" UNIQUE, btree ("tlRecordID") 
    "01f9073e-e6b8-46bf-882f-9a4cd0a_tlPayDateTime_tlExpDateTime_idx" btree ("tlPayDateTime", "tlExpDateTime")

有〜35 MIO。行。

調用簡單：

SELECT MAX("tlRecordID"::integer) AS max_id FROM "01f9073e-e6b8-46bf-882f-9a4cd0a69a66";

確實需要很長的時間。此外，更高級的查詢，如：

FROM "01f9073e-e6b8-46bf-882f-9a4cd0a69a66" 
WHERE "tlPayDateTime" != 'None' AND "tlExpDateTime" != 'None' AND 
NOW() BETWEEN "tlPayDateTime"::timestamp AND "tlExpDateTime"::timestamp GROUP BY "tlPDM"

超時很多時候等

誰能幫助優化數據庫？是35 mio。排成一個問題還是？

來源

2013-11-25 user809829

這也許會幫助你：http://stackoverflow.com/questions/11940515/postgres-performance-issues – funk

...你拍攝自己的腳，使用基於字符的類型來存儲日期/時間值（即「無」應該可能爲空）。此外，請閱讀[本博客文章]（http://sqlblog.com/blogs/aaron_bertrand/archive/2011/10/19/what-do-between-and-the-devil-have-in-common.aspx）有關使用帶有時間戳的BETWEEN的問題（這篇文章是專門針對SQL Server的，但邏輯適用於所有測量/非整數類型） –

是的，這是數據轉換問題。使用正確的數據類型是系統性能的先決條件。 –

我討厭這麼多評論，但是我認爲這樣解決這個問題會非常困難。你有一個重要的數據類型錯誤，這將引入微妙的錯誤和性能問題，並且在GUID之後命名錶不是可維護性的通用途徑。

您需要根據自己的需要將日期時間字段移至timestamp或timestamptz類型。這些文本字段不會得到良好的性能。使用NULL而不是'None'
對於您的最大id選擇，查看查詢計劃。我們不能在那裏提供任何反饋。理想情況下使用VERBOSE並告訴它顯示緩衝區的使用情況。
您不需要regclass轉換。算了吧。

來源

2013-12-12 14:20:09

正確的索引是簡單的表

回答

相關問題