通过阅读有关TOAST的一些内容，我了解到Postgres使用的是LZ系列压缩算法，它称之为PGLZ。并且它会自动启动大于2KB的值。
PGLZ在速度和压缩比方面与GZIP相比如何？
我很想知道PGLZ和GZIP是否具有相似的速度和压缩率，以便在将大型JSON字符串作为数据插入Postgres之前执行额外的GZIP步骤是不必要的或有害的。
答案 0 :(得分：3)
它明显更快，但压缩比低于gzip。它针对较低的CPU成本进行了优化。
在将数据存储到bytea字段之前，肯定有一个gzip大数据的地方，假设您不需要直接在DB中操作它，或者不介意必须使用函数来解压缩它第一。如果必须在数据库中执行此操作，则可以使用plpython或plperl之类的操作，但通常在应用程序中执行此操作会更方便。
如果您打算进行额外压缩，请考虑使用更强大的压缩方法，如LZMA。
已经努力在PostgreSQL中为TOAST添加对gzip和/或LZMA压缩的支持。这样做的主要问题是我们需要保持与旧版本的磁盘格式的兼容性，确保它在未来保持兼容等。到目前为止，没有人提出满足相关核心团队成员的实现。参见例如pluggable compression support。它往往会陷入catch-22，其中可插拔支持被拒绝（请参阅该线程的原因）但是没有人能够就我们应该采用的新的默认方法采用合适的软件专利安全算法达成一致，同意如何更改处理多种压缩方法的格式等。
答案 1 :(得分：-1)
自定义压缩方法即将成为现实。如这里报道 https://www.postgresql.org/message-id/20180618173045.7f734aca%40wp.localdomain 综合测试表明zlib提供了更多压缩，但通常 比pglz慢