當您使用TEXT數據類型時，是否存在用於插入，更新或刪除數據的某種性能差異？數據類型和索引
我去here，發現這個：
提示：使用空白填充類型時，和 一些額外的CPU週期，從增加的存儲空間有這三種類型之間沒有性能差別，除了 在存儲到長度受限的列時檢查長度。儘管字符（n）在其他一些數據庫系統中具有很好的性能，但在PostgreSQL中不存在這樣的優勢 ;實際上字符（n）通常是三個中最慢的，因爲它有額外的存儲成本。在大多數情況下，應該使用文字 或改變字符。
這讓我相信應該沒有性能差異，但我的朋友比我更有經驗，他說插入，更新和刪除對TEXT數據類型來說比較慢。
我有與觸發和功能分區，並極其嚴重索引的表，但刀片沒有去慢。
現在我有另一個表，有5分列所有這一切都是文本數據類型，完全相同的觸發器和功能，沒有指標，但刀片是非常緩慢的。
從我的經驗，我認爲他是正確的，但是你們覺得呢？
編輯＃1： 我上傳完全相同的數據，只是第二個版本有5個列。
編輯＃2： 通過「慢」我的意思是第一種情況下，我能夠每秒插入500或更多的行，但現在我只能每秒插入20行。
編輯＃3：我沒有索引添加到第二個場景就像他們是在第一方案，因爲指標都應該減慢插入，更新和刪除，從我的理解。
編輯＃4：我保證它是完全一樣的數據，因爲我是一個上傳。唯一的區別是，第二種情況有5個額外的列，所有文本數據類型。
編輯＃5：甚至當我除去所有的索引對場景2和左所有這些對方案1中，插入件仍然在方案2
編輯＃6慢：這兩種情況都具有相同的確切的觸發和功能。
編輯＃7： 我正在使用ETL工具Pentaho插入數據，因此我無法向您顯示用於插入數據的代碼。
我想我可能在ETL工具中有太多的轉換步驟。當我嘗試在與實際轉換數據的步驟相同的轉換中插入數據時，它的速度非常慢，但是當我簡單地將已轉換的數據插入空表中並將此表中的數據插入實際表格中時，使用時，插入速度比情況1快得多，每秒4000行。
場景1和場景2之間唯一的區別，除了場景2中的列增加之外，是ETL轉換中的步驟數。場景2在ETL轉換中具有大約20個或更多步驟。在某些情況下，還有50多個。
我想我可以通過減少轉換步驟數，或將轉換後的數據到一個空表，然後從該表中插入數據到我使用的是實際的表解決我的問題。
'符合......沒有索引，但插入的速度非常慢。「可能會添加索引，就像在第一個表中一樣？ （並且之後不要忘記運行'VACUUM ANALYZE'） – joop
你插入的是完全相同的數據嗎？除非我們看到實際的測試腳本，否則很難發表評論。 –
我通過編輯我的帖子回覆了你。編輯3和4 – LunchBox