в двух словах. hash join хорошо ложится на пайплайн CH поэтому в части join-а там все параллелится примерно так же хорошо, как для обычных запросов. в части построения хэш-таблицы - можно улучшить, если сделать лок-фри хэш таблицу (сейчас там mutex на вставке). merge join-ы вписываются в пайплайн сильно хуже, но там можно и нужно прокинуть инфу о сортировке из таблиц (и возможно где-то начнет обгонять hash join, когда умещаемся в память - не сильно приоритетно), join на диске вписывается очень плохо и сильно тормозит. сейчас join на диске есть только для merge join-а. в этом месте планируется сделать grace hash join (это двухуровневый hash join со скидыванием бакетов на диск) - должно работать сильно лучше текущего join-а на диске. На многопоточность это все почти никак не влияет. Основная проблема join-а на диске не гонять данные с диска в память и обратно (и  не блокироваться на ожидании этих данных).

помимо этого есть еще несколько оптимизаций про join-ы вообще, независимо от алгоритма. Там тоже не про многопоточность, а про использование доп знаний из индекса таблицы.

Спасибо, то есть, если RAM хватает, то должно все ресурсы занимать и делать эффективно?

Почему тогда у автора сообщения выше только половина ядер? Памяти не хватило?

Ну плавает ок 12-16 из 32, но там расжатие же еще и тд.
Почти половина flamegraph это wait
Но это относится к multiple join

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

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

https://github.com/Slach/clickhouse-flamegraph
настройки дефолтные

Сложно, я обычно одним sql-запросом рисую. А какой trace_type в итоге получается? По умолчанию там выбраны все, но Real и CPU ведь смешивать нельзя в один флеймграф, не говоря уже про Memory. Или оно отдельные графики для них рисует?

Для оценки использования CPU по логу запросов мб подойдёт UserTimeMicroseconds из ProfileEvents (это сумма времени CPU для всех потоков запроса), делёное на query_duration_ms -- получается как бы эффективное количество потоков.

можно и альтером добавить к существующей,  это обычная таблица

Скажите ещё, если надо обогатить маленькую таблицу (на 1к строк) при помощи большой (миллиард и более строк), то можно ли заставить СН 1000 раз дернуть данные из большой по PK вместо hash join? И желательно, чтобы это все в параллели

я вот сделал TTL  event_date + toIntervalWeek(1), чтоб удалялись данные старше недели.
но по факту ничего не произошло.  или старые данные которые были до применения TTL надо самому удалить?