заблочит в каком смысле?
так default их заполнит

ну 2млрд записей мгновенно не обновятся, скажем, это будет за 5 минут. За это время придет еще 100к новых строк данных. И все они будут ждать, пока довыполнится ALTER? Или они потеряют это вычисление DEFAULT?

Может я, конечно, не туда пошел вообще? Изначальная задача такая: в целях оптимизации времени выполнения аналитических запросов, нужно достать частоиспользуемые поля из json-поля и материализовать в колонки. Мне показалось, что материализованные колонки как раз для такой задачи и нужны. Делать по материализованной вьюхе на каждое поле было бы избыточно, да и JOIN тогда пришлось бы делать, что совсем плохо.

нет alter не блокирует инсерты и селекты
инсерты заполнят DEFAULT

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

хм, окей. Просто уже сейчас некоторые запросы до 20 минут могут выполняться, поэтому хотелось бы, чтобы буст был сразу заметен, а не спустя недели. Поэтому и пытаюсь материализовать сразу)

Спасибо, получилось. Именно то, что нужно !

Ребят, может подсказать кто-нибудь? Есть табличка ReplacingMergeTree, есть в ней дубли. При чём дубли в неожиданных местах, раз в несколько месяцев просто появляются и никуда не исчезают. Запись в таблицу постоянно происходит, ну и схлопывание более-менее нормально отрабатывает, а тут столкнулись с дублями. Подскажите куда копать, как исправить, если возможно, и почему старые записи не оптимизируются одновременно с новыми. Спасибо

А можно ли в Tabix, DBeaver передать пользовательские настройки, префиксы которых которые определены в  <custom_settings_prefixes> ?

так, а если может быть только одна пара событий - есть решение эффективнее?

session_id, minIf(event=start) b, maxIf(event=stop) e , e-b
group by session_id

прямо в конец select .... from view .... settings my_custom_x = '...'

Merges are eventual and may never happen. It depends on the number of inserts that happened after, the number of parts in the partition, size of parts.
If the total size of input parts bigger than the maximum part size then they will never be merged.

https://clickhouse.tech/docs/en/operations/settings/merge-tree-settings/#max-bytes-to-merge-at-max-space-in-pool

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replacingmergetree/
Thus, ReplacingMergeTree is suitable for clearing out duplicate data in the background in order to save space, but it doesn’t guarantee the absence of duplicates.

ну в принципе мой вариант для нескольких пар событий через sumIf(±ts) практически так же работает. только будут проблемы, если будет много непарных событий. думаю, жить можно

хотя можно поверх запилить anyLastIf(counter%2==0, sum)

спасибо за помощь еще раз :)

удалили, теперь пишет что словарь не найден, когда обращаемся через dictGet
как сделать так чтобы, когда указываешь литерал словаря не нужно было писать dictionary.dict_name?

никак. Это сделано специально чтобы dictGet мог понять какой словарь запрашивают

но он же должен понимать что если это словарь то подставить схему dictionary?

имя базы, мы про имя базы?