Часть строки (набор последывательных полей) часто повторяющаяся может заменятся на более короткий ключ, полное же значение хранится в Side Table (хэндлится полностью автоматически)
В пулах тоже сжатые значения, не только на дисках.
Для вычисляемых выражений значения само собой должны декомпрессироваться.

Есть возможность управлять Side Table - словарем.
Каталог изменен в части касающейся. И статистика тоже собирается с учетом.
И snapshot изменен и позволяет мониторить.
И даже Advisor есть.

Не по теме замечание.
Я не буду сюда перепечатывать все руководство с примерами, но часто обновляемые данные:
а) не есть хорошие кандидаты для сжатия по ряду причин, и уникальных значений у них может быть больше и прочее
б) и зачем их вообще сжимать, если это ОПЦИОНАЛЬНО?

Вона LDAP так вообще асинхронная тихнология в смысле что доступ к данным на чтение заведомо гораздо быстрее, чем запись и модификация.
И что - на помойку? Или таки использовать учитывая особенности?

Вы своим умствованием немного утомили.
Как говорит НАШ великий Жванецкий "Не нравится - отойди и не нюхай"
Тоже не по теме, кстати :)

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