А не подскажите, какой параметр в конфиге брокера за это может отвечать?

привет)
можете подсказать  решение такой задачи:
есть таблица в PostgreSQL. Можно как-то настроить, чтобы данные при  инсерте в PG-таблицу вставлялись в соответствующую таблицу в КХ?

Привет. Кто-нибудь знает как тут https://clickhouse.tech/benchmark/dbms/#[%22100000000%22,[%22ClickHouse%22,%22InfiniDB%22],[%221%22]] вычислается "Relative query processing time" ?

Это не среднее, не среднее квадратичное (и не в третьей / полуторной степени))? Что за формула? Нормализация какая-то идёт, непонятно по чему.

https://t.me/clickhouse_ru/200852
вот тут =)

и тут
https://t.me/clickhouse_ru/168468

короче, выключите и руками управляйте =)

наконец то хоть кто-то ещё напоролся =)

читал,  спасибо
но так и не понял - оно обновляет TTL для старых данных без MATERIALIZE TTL?

/stat@combot

Total messages: 201943

ура, т.е. клиент теперь сам делает мердж!
т.е. теперь не будет валится это:
https://t.me/clickhouse_ru/199499

будем посмотреть

там столько чёрной магии и изменений в этом master-ишшю, что в зависимости от версии может происходить что угодно. надо проверять.
в теории настройка ТТЛ должна быть на уровне таблицы, а в парте только значение которое проверяется + подсчитанное выражение мин-макс... но на деле черт ногу сломит... в итоге все на скриптах. вот когда все галочки проставятся можно дальше проверять...

теперь будет много вопросов почему вставляется разное количество строк через клиент vs http =)

ясно, вариантов все равно никаких ибо materialize ttl как-то совсем неадекватно работает

да, у нас аж два раза стрельнул =) и то, что он при отсутствии изменений только делает хардлинки вообще нифига не спасает при replicatedMT+>100 partition

Обновились таки, запись не отключали, у нас была не сама свежая версия 19.16, от этого вначале словили https://github.com/ClickHouse/ClickHouse/issues/11041#issuecomment-630854237
Быстренько кластер обновили до 19.16.19.85 и поехали накатывать lts дальше.
Так же пришлось немного поправить код приложений которые пишут - у нас вставки были через TabSeparatedWithNames но старый КХ по факту столбцы сопоставлял по порядку, по этому шапка особо не мешала даже если имена в шапке tsv  не совпадали с колонками. А новый КХ начал пытаться сопоставлять, и они не совпали. Просто убрали шапку в общем и все.

В остальном полет пока нормальный, спасибо за советы.

особеный шок был когда он начал перезапись на "TTL MOVE" =)

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

ttl_only_drop_parts=true?

да

у нас так было в 20.3, про ХЛ саппорт из альтинити сказал, мопед не мой (может позже добавили)
https://t.me/clickhouse_ru/200370 вот тут

перелопачивать на самом деле все равно придется, так как придется например добавить/удалить информацию о минмакс колонки в парт... просто там надо оптимизировать аггрессию materialize ttl доп свойствами + не мутировать при неизменении колонки (например при убирании ТТЛ либо при изменении 8 дней на 10) или при использовании колонки у которой уже есть минмакс (партишнключ)

как в мастер ишшю сказано:
A large number of background TTL operations using the same disk with many threads can actually hurt performance due to disk I/O bottleneck. Need a separate resource management. So we need a control over:
Number of threads.
Priority (default -- lower than queries and merges).
TTLs at the beginning of the policy should be executed first (usually first volume is the smallest).
===
(хотя как по мне проблема жизнь сильно портится именно в replicatedMT)