хмм
Cannot MATERIALIZE TTL as there is no TTL set for table system.query_thread_log (version 20.5.3.27 (official build))
вот вырезка из конфига
<query_thread_log>
       <database>system</database>
       <table>query_thread_log</table>

       <engine>ENGINE = MergeTree PARTITION BY (event_date) ORDER BY (event_date, event_time) TTL  event_date + toIntervalWeek(1)   SETTINGS min_bytes_for_wide_part = '10M', index_granularity = 8192, ttl_only_drop_parts=1 </engine>
       <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_thread_log>

Не очень понимаю. Например, если в большой хранятся все посещения страниц всеми юзерами, и PK user_id, timestamp .
А в маленькой предварительно обработанный батч юзеров, по которым надо добавить инфу по посещениям.
И я хочу сделать аналог join, но не фуллсканить большую, а 1000 раз сходить в нее по ПК

таблица уже была, ваши изменения применятся при создании таблицы, (когда ее нет), переименуйте rename table system.query_thread_log to system.query_thread_log_old и еще рестарт КХ нужен, иначе эти изменения конфига не видны

Хеш таблицы же в начала только строятся? 1600 samples против 100к
Выполнилось за 2 секунды
Сам основной запрос за секунд 200 выполняется.

вешаете на большую словарь с PK user_id. Делаете "SELECT * FROM small_table SEMI LEFT JOIN dict WHERE ...". Внутри это будет выглядеть как dictGet(user_id) для каждого левого ключа small_table.user_id, без предварительного построения hash-таблицы по большой. работает не для всех типов join-а (по понятным причинам). какой-нибудь FULL JOIN без сообщений об ошибке свалится в построение таблицы и обычный hash join в этом случае

спасибо.  рестар делал после изменения конфига. на существующей таблице не применилось получается.
переименовал и тут же появилась новая таблица,  с правилами. спасибо!
ps. скопировал данные со старой  в новую. применил ALTER table system.query_thread_log  MATERIALIZE TTL.
и данные старше недели удалились!

это asof или обычный?

обычный
два INNER JOIN
multiple_join_rewriter = 2

multiple_join_rewriter = 2 - не влияет на скорость, только на корректность

давайте issue сделаем. на вскидку не ясно, что там. нужна схема и какой-то простенький генератор данных типа insert select в таблицу.

надо как-то воспроизвести, чтобы погонять с большим количеством диагностики

если можете, запустите дебажную сборку с тем же флеймом, там будет получше стек - может по нему что-то станет видно. сейчас кондвар непонятно где

Да, хорошо.
Данные это Star Schema Benchmark.
Но 300гб грузить смысл не думаю, что есть.
Попробую генератор накидать.

arrayMap(x -> arraySlice(summ, 1, x), arrayEnumerate(summ)) AS cum_summ

лучше так не делать, жопа в том что summ будет размножаться лямбдой, т.е. arrayEnumerate(summ) создаст массив [1...1000], summ тысячу раз скопируется в памяти.

лучше избегать arrayEnumerate и передачи массива в лямбду, почти всегда это достижимо потому что все (нужные) ФВП принимают несколько массивов (аргументов лямбды)

Доброго всем дня. Подскажите можно ли в качестве HTTP(s)  source для External Dictionary подсунуть url/file.csv.gz  (gzip archive) ?

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

Спасибо, то есть, это обыкновенный secondary index, по аналогии с другими субд, получается по сути?

с точки зрения join-а это ближе к lookup алгоритму (или nested loop), со вторичным индексом не очень понял аналогию

в смысле alter delete ?  не вызовет.

user_id все равно надо иметь где-то в первичном ключе большой таблицы, чтобы не перечитывать ее всю