Всем доброго времени суток!

Есть живые пользователи данной фичи от АСЕ?

Сказалось ли как-то на производительности системы (нагрузка на проц/может быть замедление процессов/времени доступа к данным и т.п.)?
В доках все очень красиво расписано, но зная Сайбез, хотелось бы понять подводные камни процесса...

Специфика текущей базы - множество text-полей (хранятся ХМЛки).
Парсинг этих ХМЛок.

P.S.: есть определенные планы в ближайшее время запользовать тестово фичу, но хотелось бы заранее понять к чему готовиться, и какие грабли могут вылезти :)

Nashville, спасибо!

А с In-Row lob не приходилось сталкиваться?
Сейчас тестово "погонял" настройки, заметил непонятную вещь: да, 255-ый индекс прилично сжимается (ситуация не с хранением в Text-поле ~100-150 символов). Но при этом на таблице растет unsed space и не высвобождается ничем...
Reorg rebuild/reorg reclaim_space не помогают... Не совсем понятно поведение.

тип TEXT

Удалось в живую "пощупать" ASE-Compression.
Из основных ощущений:
1. непонятно, зачем они сделали несколько уровней сжатия.
Эффект между 1 и 9 - порядка 4-5%, при изначальном эффекте в ~50-55% на моих данных.
Возможно у меня какая-то особенность в данных, но вроде бы просто текст.

2. пока не удалось почувствовать разницу между ZLib и FastLZ, но основное нагрузочное тестирование еще впереди.

3. натолкнулся на "особенность" если уже существующую колонку модифицировать под компрессию и в этой же таблице есть вычисляемые колонки, основанные на изменяемой = ASE выдает ошибку. И требует сначала дропнуть вычисляемые колонки...
В документации с таким не сталкивался => не самая приятная неожиданность :-).

Пришлось дропать колонки, что потянуло за собой перестроение индексов + колонки само собой нужно будет вернуть.
Но, видимо, на то есть тайный смысл/замысел.