CFS — сжатие на уровне страниц СУБД в Postgres Pro

Как видно из графика, долго выполняющихся запросов стало значительно меньше, в остальном поведение системы почти не изменилось.

Из графика видно, что мы ускорили 250 медленных запросов, замедлив миллион относительно быстрых.

Как убить "либидо" до ката: "PG CLASTER 3" ?

Тут не хватает сравнения того, насколько меняется производительность + сравнения с фс с сжатием, те же btrfs, zfs.
У меня есть БД на обеих, в зависимости от того, что пишется уровень компресии составляет для
btrfs: lzo ~2 (тип данных, пусть будет 1), zstd-3 ~4 (на тех же данных 1), zstd-9 ~9 (на логоподобных).
zfs: lz4 2.3 (на 1), zstd-3 ~4 (на 1).

А индексы тоже сжимается или только данные в таблицах?

Ну и наверное есть повышенное требование на оперативную память, ведь поднять в память кусок таблицы и распаковать займёт теперь в 5 раз больше места, или это не так?

Как распаковка данных влияет на требования к cpu, теперь же кроме джойнов нужно ещё и распаковку выполнять, особенно сильно должно в много пользовательского системе влиять, делали ли такие замеры?

Сэкономить место на диске можно, например, компрессией VDO. Интересней, как в MS SQL, сэкономить еще и оперативную память, храня в ней сжатые страницы. А вот этот вопрос в статье как-то обойден стороной. Так shared buffers содержит сжатые страницы или уже нет?

Интересно, когда уже поднимут 1С на Greenplum

в PG PRO пару - тройку раз делаешь подряд

update mycompressed_table set field=field+1

И вуаля, -- размер временно будет больше чем без компресии. Так как всегда происходит запись обновленных блоков в конец. То есть резерв диска должен быть даже больше чем без компресии для таких случаев иначе update не пройдет.