對于列壓縮選項，PostgreSQL 14提供了新的壓縮方法LZ4。與TOAST中現有的PGLZ壓縮方法相比，LZ4壓縮更快。本文介紹如何使用整個選項，并和其他壓縮算法進行性能比較。
背景
PG中，頁是存儲資料的機關，預設是8KB。一般情況下，一行資料不允許跨頁存儲。然而，有一些變長的資料類型，存儲的資料可能超出一頁大學。為了克服整個限制，大字段域會被壓縮或者分割成多個實體行。這個技術就是TOAST：
https://www.postgresql.org/docs/14/storage-toast.html
預設情況下，如果表中有變長列，行資料的大小超過TOAST_TUPLE_THRESHOLD（預設2KB）就會觸發TOAST。首先，會先壓縮資料；壓縮後如果仍然太大，會溢出存儲。需要注意，如果列的存儲政策指定EXTERNAL/PLAIN，壓縮會被禁止。
PG14之前版本，TOAST僅支援一個壓縮算法PGLZ（PG内置算法）。但是其他壓縮算法可能比PGLZ更快或者有更高的壓縮率。PG14中有了新壓縮選項LZ4壓縮，這是一個以速度著稱的無損壓縮算法。是以我們可以期望它有助于提高TOAST壓縮和解壓縮的速度。
如何使用LZ4？
為了使用LZ4壓縮特性，在編譯時需要指定--with-lz4，并且在作業系統中按照LZ4庫。通過GUC參數default_toast_compression可以指定PG執行個體的TOAST預設壓縮算法。可以在postgresql.conf中配置，也可以通過SET指令僅改變目前連接配接：
postgres=# SET default_toast_compression=lz4;
SET 複制
在CREATE TABLE建立表時指定列壓縮算法：
postgres=# CREATE TABLE tbl (id int,
postgres(# col1 text COMPRESSION pglz,
postgres(# col2 text COMPRESSION lz4,
postgres(# col3 text);
CREATE TABLE
postgres=# \d+ tbl
Table "public.tbl"
Column | Type | … | Storage | Compression | …
-------+---------+---+----------+-------------+ …
id | integer | | plain | |
col1 | text | | extended | pglz |
col2 | text | | extended | lz4 |
col3 | text | | extended | |
Access method: heap 複制
我們使用\d+指令可以看到所有列的壓縮算法。如果列不支援或者沒有指定壓縮算法，那麼會在Compression列顯示空格。上面的例子中，id列不支援壓縮算法，col1列使用PGLZ，col2使用LZ4，col3沒有指定壓縮算法，那麼它會使用預設的壓縮算法。
可以通過ALTER TABLE修改列壓縮算法，但需要注意，修改後的算法僅影響執行整個指令後的insert資料。
postgres=# INSERT INTO tbl VALUES (1, repeat('abc',1000), repeat('abc',1000),repeat('abc',1000));
INSERT 0 1
postgres=# ALTER TABLE tbl ALTER COLUMN col1 SET COMPRESSION lz4;
ALTER TABLE
postgres=# INSERT INTO tbl VALUES (2, repeat('abc',1000), repeat('abc',1000),repeat('abc',1000));
INSERT 0 1
postgres=# SELECT id,
postgres-# pg_column_compression(id) AS compression_colid,
postgres-# pg_column_compression(col1) AS compression_col1,
postgres-# pg_column_compression(col2) AS compression_col2,
postgres-# pg_column_compression(col3) AS compression_col3
postgres-# FROM tbl;
id | compression_colid | compression_col1 | compression_col2 | compression_col3
---+-------------------+------------------+------------------+------------------
1 | | pglz | lz4 | lz4
2 | | lz4 | lz4 | lz4
(2 rows) 複制
可以看到在修改壓縮算法前插入的行，col1仍使用PGLZ壓縮算法，即使将壓縮算法從PGLZ修改到了LZ4。（那麼，修改後進行解壓時使用哪個算法呢？）
需要注意，如果從其他表掃資料插入本表，例如CREATE TABLE ...AS...或者INSERT INTO...SELECT...，插入的資料使用的壓縮算法仍然使用原始資料的壓縮方法。pg_dump和pg_dumpall也添加了選項--no-toast-compuression，使用整個選項後，不會dump出TOAST壓縮選項。
性能比較
測試了LZ4和PGLZ壓縮率和壓縮速度。并添加了未壓縮資料的測試結果（指定存儲政策為EXTERNAL），對于未壓縮資料，沒有壓縮和解壓的耗時，但讀和寫資料的時間會增加。
測試使用的資料：PG documents（一行資料一個HTML檔案）；SilesiaCorpus提供的資料，包括HTML、Text、源代碼、可執行二進制檔案、圖檔：
https://github.com/MiloszKrajewski/SilesiaCorpus
測試機器使用Intel® Xeon® Silver 4210 CPU @2.20GHz with 10 cores/20 threads/2 sockets。
使用pgbench測試SQL語句執行時間，pg_table_size檢查表大學（每次執行前都執行VACUUM FULL排除死記錄的影響）。
壓縮率
PGLZ和LZ4的壓縮率都依賴于重複資料，重複的元組越多，壓縮率越高。但是如果PG評估這樣的壓縮率不好時，就不會執行壓縮，即使資料大小達到了門檻值。因為壓縮并沒有高效節省磁盤空間，還會帶來解壓鎖的額外時間和資源消耗。
目前PG14中，PGLZ需要至少25%的壓縮率，LZ則僅比未壓縮資料時小即可。我比較了LZ4、PGLZ的表與未壓縮表大小。可以看到，大部分場景下，PGLZ的壓縮率稍微好點，壓縮率評價為2.23，LZ4的壓縮率為2.07。這意味着PGLZ可以節省7%的磁盤空間。
Figure 1 - Comparing table sizes (in KB)
壓縮/解壓縮速度
Insert和查詢時TOAST資料會被壓縮和解壓縮。是以，我執行一些SQL語句檢視不同壓縮算法帶來的影響。
首先比較了INSERT語句，列使用LZ、PGLZ和未使用壓縮時的性能。可以看到與未壓縮資料比，LZ4耗費稍微多一點時間，PGLZ耗費時間更多。LZ4的壓縮時間比PGLZ平均節省20%。這是一項非常顯著的改進。
Figure 2 - Comparing INSERT performance
下面比較SELECT。與PGLZ相比，LZ4可以節省20%的時間，與未壓縮資料相比，沒有太大差别。解壓縮的消耗已經降到了很低了。
Figure 3 - Comparing SELECT performance
再比較16個用戶端的INSERT語句并發。與PGLZ相比使用LZ4的單大檔案（HTML，英文文本，源代碼，二進制執行檔案，圖檔）的壓縮性能快60%-70%。插入多個小檔案（PG文檔），性能提升不大。和未壓縮的資料相比，有巨大提升，猜測使用壓縮減少了寫入磁盤的資料量。
Figure 4 - Comparing INSERT performance with 16 clients
16個用戶端的SELECT，多數場景下，LZ4性能優于PGLZ：
Figure 5 - Comparing SELECT performance with 16 clients
同樣也比較了使用字元串函數的SELECT、UPDATE處理文本的速度。整個場景下LZ4優于PGLZ。LZ4壓縮算法的資料與未壓縮資料相比，函數處理的速度幾乎一樣，LZ4算法幾乎不會影響字元串操作速度。
Figure 6 - Comparing performance using string functions
與PGLZ相比，LZ4壓縮和解壓縮TOAST資料更加高效，并提供很好的性能。和未壓縮資料相比，查詢速度幾乎一樣，和PGLZ相比，插入快80%。當然某些場景下壓縮率不太好，但如過你想要提升執行速度，強烈推薦使用LZ4算法。
同樣需要注意，需要考慮表中的資料是否合适壓縮。如果壓縮率不好，它仍然會嘗試壓縮數，然後放棄。這将導緻額外的記憶體資源浪費，并極大影響插入資料的速度。
未來
LZ4對TOAST的壓縮和解壓縮性能帶來了很大提升。除了LZ4，還有很多其他壓縮算法比如Zstandard。支援Zstandard使用者可以得到比PGLZ更好的壓縮率。LZ4 HC具有比LZ4解壓98.5%的壓縮速度，但是可以大幅提升壓縮率。希望未來PG版本可以使用更多的壓縮算法。
除了TOAST外，其他場景也需要壓縮。據我所知，目前開發版本已經支援WAL的LZ4壓縮，這是一項令人興奮的特性。
原文
https://www.postgresql.fastware.com/blog/what-is-the-new-lz4-toast-compression-in-postgresql-14