Мне нужно сохранять в таблицу хекс-значения максимально компактно (FixedString). в

запросах это значение прилетает как строка например 'a567c902fe869d'.

можно ли создать таблицу в которой фактически записываемое значение в столбец будет результатом от значения в инсерте?

сейчас сделал дополнительную колонку как
FixedString(8) MATERIALIZED unhex(reinterpretAsString(hex_string))

но мне исходное значение в таблице не нужно вообще

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

Можно преобразовывать в инсёртящем запросе или вставлять в таблицу с движком Null, а на неё навесить MV, которое будет делать нужные преобразования.

А можете дать простой пример - я не понял к сожалению ((

Alexey уже ответил, хотел добавить почему ИМХО это хорошо желательно лить в CH данные подготовленными, а вам в таблице hex не нужен поэтому вы в начале можете сделать null + mv, а уже когда научитесь (если есть в планах) подготавливать данные, будете сразу в таблицу лить

на исходное значение можно короткий TTL какой нибудь навесить чтобы оно потом удалялось при мержах

Про подготовку данных перед загрузкой в кх это понятно А в чём преимущество схемы с Null + MaterializedView перед использованием временной таблицы?

я не совсем понимаю, как вы хотите использовать временную таблицу заливаете во временную, insert select, truncate?

ну да примерно так заливаю во временную, а из неё уже insert select в постоянную в идеале было бы перобразовать данные прямо в инсерте, но как я понял это не возможно

в таком случае почитайте про MV алгоритм с Null + MV + target table: insert into Null в Null таблицу пишите hex, в итоговую летит unhex, но можно и с ttl, как вам удобнее

я почитал и даже что то вроде понял в документации примеров я не нашёл (( гугл пока тоже не очень то помогает

хотя сейчас вроде получилось прямо в инсерте конвертировать значение в любом случае, спасибо

Покажите, как вы это делаете, я что-то не понимаю Интересно:)

create table test1 (hex_compact FixedString(16)) engine = MergeTree () insert into table test1 (hex_compact) values (unhex(reinterpretAsString('a7ca8a7f9a78f501f594e40dd8dc2de6'))) вот так вроде работает но это всё ок для тестового примера а в таблице там 40+ колонок и ковертаций мне нужно 3 или 4 нашёл вроде пример использования Null + MV для вставки с перобразованием - разбираюсь

Плюсы есть: 1. Ненужные данные вообще не будут храниться и мерджиться. 2. Не нужно внешней приложухи, которая будет делать все эти переливания\конвертации по таймеру 3. Преобразования будут происходить не раз в N времени над большим объёмом записей, а в реальном времени над небольшими пачками данных. Пример сейчас неудобно печатать. Общий смысл: делаете одну таблицу с движком Null с полями как в источнике - она будет нужна только как точка входа для работы MV, делаете вторую таблицу с нужным движком и правильными полями - это будет само хранилище, делаете MV на первую таблицу - оно будет преобразовывать данные по мере поступления и складывать их в хранилище в нужном виде.

Понял, нашёл пример использования Null + MV - как раз разбираюсь с ним. Это позволяет мне реализовать текущие хотелки. Спасибо за пинок в правильном направлении

как раз протестирую как оно отработает заливку из старой базы на 600+ млн записей

можно через input() функцию