帶有大文本和字節的詳細優化列順序
我閱讀了這個關於最佳列排序的優秀答案，並註意到了總結：
一般來說，如果你把 8 字節類型放在前面，然後把 4 字節類型和 2 字節類型放在最後，你就不會出錯。文本或布爾值沒有這樣的對齊限制，其他一些類型有。最後，您最多可以每行節省幾個字節。因此，在大多數情況下，對於大多數人來說，這些都不是必需的。但在您的情況下，它可能會輕鬆節省幾千兆字節。
這是否意味著列應該從空間佔用最多到最少？
如果是這樣，對於
bytea始終具有恆定 16 字節、32 字節或 64 字節長度的列，是否適用相同的規則？文本列在 1kb 到 5mb 之間變化，嚴重偏斜到 1kb 呢？這些
bytea列是在所有讀取條件中使用的變數。這張表的長度上限是每年數百億行。
這是否意味著列應該從空間佔用最多到最少？
不，不一定。您可以播放“列俄羅斯方塊”以最小化填充，從而節省一些空間。我給出的和你引用的經驗法則是需要對齊的基本類型的一種簡單策略。
正如我在引用的答案
pg_column_size()中提到的，您可以在整行上測試實際儲存大小（不包括項目標識符） 。
text和相關varchar的和char類型不需要填充，所以沒有任何收穫。bytea您的列也是如此。關於儲存大小：
始終具有恆定 16 字節、32 字節或 64 字節長度的 bytea 列
Storage Size 1 or 4 bytes plus the actual binary string
bytea這意味著， 16 字節、32 字節或 64 字節長度的列所需的實際空間分別為 17 或 20 字節、33 或 36 字節等。正如這個SQL Fiddle中所展示的，一個
bytea變數總是有 4 個字節的成本。然而，當儲存在一個列中時，它開始時只有 1 個字節的成本，然後切換到 4 個字節的長度為 127 個字節或更長的值。為行類型添加了 24 字節的成本。
數據頁中每個元組的項目標識符需要另外 4 個字節。此相關答案中的詳細資訊：
至於 的對齊要求
bytea，根據文件：具有單字節標頭的值也不在任何特定邊界上對齊。
我建議你閱讀整章——可能要讀幾遍，這很難讀。