Комментарии 12
Как видно из графика, долго выполняющихся запросов стало значительно меньше, в остальном поведение системы почти не изменилось.
Из графика видно, что мы ускорили 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 не пройдет.
CFS — сжатие на уровне страниц СУБД в Postgres Pro