Как стать автором
Обновить

Комментарии 12

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

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

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

живем мы не в мире розовых поней. всё упирается в бюджеты. диски для БД и СХД - сукадорогие.
уменьшение объема занимаемого места БД, без снижения производительности - это уже восторг.

дали бы возможность выбирать включение/выключение сжатия по типу данных, или по отдельным таблицам...

По отдельным таблицам через тейблспейсы же

спасибо,

но я вообще про другое.

Тут возникает вопрос стоимости лицензий. Есть подозрение, что на разницу стоимости лицензий между Postgres и Postgres Pro Enterprise можно купить очень много дисков.

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

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

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

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

Сжимается всё, и индексы в том числе
Повышенный расход памяти не зафиксирован
По поводу cpu в статье отразил, что на уровне погрешности измерений 1,5% рост нагрузки
Замеры делались на системе с 500+ одновременно работающих пользователей

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

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

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

update mycompressed_table set field=field+1

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий