對于列壓縮選項，PostgreSQL 14提供了新的壓縮方法LZ4。與TOAST中現(xiàn)有的PGLZ壓縮方法相比，LZ4壓縮更快。本文介紹如何使用整個選項，并和其他壓縮算法進行性能比較。

背景

PG中，頁是存儲數(shù)據(jù)的單位，默認是8KB。一般情況下，一行數(shù)據(jù)不允許跨頁存儲。然而，有一些變長的數(shù)據(jù)類型，存儲的數(shù)據(jù)可能超出一頁大學(xué)。為了克服整個限制，大字段域會被壓縮或者分割成多個物理行。這個技術(shù)就是TOAST：

默認情況下，如果表中有變長列，行數(shù)據(jù)的大小超過TOAST＿TUPLE＿THRESHOLD（默認2KB）就會觸發(fā)TOAST。首先，會先壓縮數(shù)據(jù)；壓縮后如果仍然太大，會溢出存儲。需要注意，如果列的存儲策略指定EXTERNAL／PLAIN，壓縮會被禁止。

PG14之前版本，TOAST僅支持一個壓縮算法PGLZ（PG內(nèi)置算法）。但是其他壓縮算法可能比PGLZ更快或者有更高的壓縮率。PG14中有了新壓縮選項LZ4壓縮，這是一個以速度著稱的無損壓縮算法。因此我們可以期望它有助于提高TOAST壓縮和解壓縮的速度。

如何使用LZ4？

為了使用LZ4壓縮特性，在編譯時需要指定－－with－lz4，并且在操作系統(tǒng)中按照LZ4庫。通過GUC參數(shù)default＿toast＿compression可以指定PG實例的TOAST默認壓縮算法?？梢栽趐ostgresql．conf中配置，也可以通過SET命令僅改變當(dāng)前連接：

postgres＝＃ SET default＿toast＿compression＝lz4；

SET

在CREATE TABLE創(chuàng)建表時指定列壓縮算法：

我們使用d＋命令可以看到所有列的壓縮算法。如果列不支持或者沒有指定壓縮算法，那么會在Compression列顯示空格。上面的例子中，id列不支持壓縮算法，col1列使用PGLZ，col2使用LZ4，col3沒有指定壓縮算法，那么它會使用默認的壓縮算法。

可以通過ALTER TABLE修改列壓縮算法，但需要注意，修改后的算法僅影響執(zhí)行整個命令后的insert數(shù)據(jù)。

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。（那么，修改后進行解壓時使用哪個算法呢？）

需要注意，如果從其他表掃數(shù)據(jù)插入本表，例如CREATE TABLE ．．．AS．．．或者INSERT INTO．．．SELECT．．．，插入的數(shù)據(jù)使用的壓縮算法仍然使用原始數(shù)據(jù)的壓縮方法。pg＿dump和pg＿dumpall也添加了選項－－no－toast－compuression，使用整個選項后，不會dump出TOAST壓縮選項。

性能比較

測試了LZ4和PGLZ壓縮率和壓縮速度。并添加了未壓縮數(shù)據(jù)的測試結(jié)果（指定存儲策略為EXTERNAL），對于未壓縮數(shù)據(jù)，沒有壓縮和解壓的耗時，但讀和寫數(shù)據(jù)的時間會增加。

測試使用的數(shù)據(jù)：PG documents（一行數(shù)據(jù)一個HTML文件）；SilesiaCorpus提供的數(shù)據(jù)，包括HTML、Text、源代碼、可執(zhí)行二進制文件、圖片

測試機器使用Intel? Xeon? Silver 4210CPU＠2．20GHz with 10 cores／20 threads／2 sockets。

使用pgbench測試SQL語句執(zhí)行時間，pg＿table＿size檢查表大學(xué)（每次執(zhí)行前都執(zhí)行VACUUM FULL排除死記錄的影響）。

壓縮率

PGLZ和LZ4的壓縮率都依賴于重復(fù)數(shù)據(jù)，重復(fù)的元組越多，壓縮率越高。但是如果PG評估這樣的壓縮率不好時，就不會執(zhí)行壓縮，即使數(shù)據(jù)大小達到了閾值。因為壓縮并沒有高效節(jié)省磁盤空間，還會帶來解壓鎖的額外時間和資源消耗。

當(dāng)前PG14中，PGLZ需要至少25％的壓縮率，LZ則僅比未壓縮數(shù)據(jù)時小即可。我比較了LZ4、PGLZ的表與未壓縮表大小?？梢钥吹?，大部分場景下，PGLZ的壓縮率稍微好點，壓縮率評價為2．23，LZ4的壓縮率為2．07。這意味著PGLZ可以節(jié)省7％的磁盤空間。

Figure 1 － Comparing table sizes （in KB）

壓縮／解壓縮速度

Insert和查詢時TOAST數(shù)據(jù)會被壓縮和解壓縮。因此，我執(zhí)行一些SQL語句查看不同壓縮算法帶來的影響。

首先比較了INSERT語句，列使用LZ、PGLZ和未使用壓縮時的性能?？梢钥吹脚c未壓縮數(shù)據(jù)比，LZ4耗費稍微多一點時間，PGLZ耗費時間更多。LZ4的壓縮時間比PGLZ平均節(jié)省20％。這是一項非常顯著的改進。

Figure 2 － Comparing INSERT performance

下面比較SELECT。與PGLZ相比，LZ4可以節(jié)省20％的時間，與未壓縮數(shù)據(jù)相比，沒有太大差別。解壓縮的消耗已經(jīng)降到了很低了。

Figure 3 － Comparing SELECT performance

再比較16個客戶端的INSERT語句并發(fā)。與PGLZ相比使用LZ4的單大文件（HTML，英文文本，源代碼，二進制執(zhí)行文件，圖片）的壓縮性能快60％－70％。插入多個小文件（PG文檔），性能提升不大。和未壓縮的數(shù)據(jù)相比，有巨大提升，猜測使用壓縮減少了寫入磁盤的數(shù)據(jù)量。

Figure 4 － Comparing INSERT performance with 16 clients

16個客戶端的SELECT，多數(shù)場景下，LZ4性能優(yōu)于PGLZ：

Figure 5 － Comparing SELECT performance with 16 clients

同樣也比較了使用字符串函數(shù)的SELECT、UPDATE處理文本的速度。整個場景下LZ4優(yōu)于PGLZ。LZ4壓縮算法的數(shù)據(jù)與未壓縮數(shù)據(jù)相比，函數(shù)處理的速度幾乎一樣，LZ4算法幾乎不會影響字符串操作速度。

Figure 6 － Comparing performance using string functions

與PGLZ相比，LZ4壓縮和解壓縮TOAST數(shù)據(jù)更加高效，并提供很好的性能。和未壓縮數(shù)據(jù)相比，查詢速度幾乎一樣，和PGLZ相比，插入快80％。當(dāng)然某些場景下壓縮率不太好，但如過你想要提升執(zhí)行速度，強烈推薦使用LZ4算法。

同樣需要注意，需要考慮表中的數(shù)據(jù)是否合適壓縮。如果壓縮率不好，它仍然會嘗試壓縮數(shù)，然后放棄。這將導(dǎo)致額外的內(nèi)存資源浪費，并極大影響插入數(shù)據(jù)的速度。

未來

LZ4對TOAST的壓縮和解壓縮性能帶來了很大提升。除了LZ4，還有很多其他壓縮算法比如Zstandard。支持Zstandard用戶可以得到比PGLZ更好的壓縮率。LZ4 HC具有比LZ4解壓98．5％的壓縮速度，但是可以大幅提升壓縮率。希望未來PG版本可以使用更多的壓縮算法。

除了TOAST外，其他場景也需要壓縮。據(jù)我所知，目前開發(fā)版本已經(jīng)支持WAL的LZ4壓縮，這是一項令人興奮的特性。