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

👍

Привет! Помогите разобраться. Нужно изменить запрос чтобы получился необходимы результат

SELECT *
FROM (
     SELECT 1 AS a, 5 AS b
     UNION ALL
     SELECT 2 AS a, 5 AS b
     UNION ALL
     SELECT 3 AS a, 6 AS b
     UNION ALL
     SELECT 4 AS a, 7 AS b
     UNION ALL
     SELECT 5 AS a, 8 AS b
     UNION ALL
     SELECT 6 AS a, 9 AS b
     UNION ALL
     SELECT 7 AS a, 10 AS b
     UNION ALL
     SELECT 8 AS a, 10 AS b
     UNION ALL
     SELECT 9 AS a, NULL AS b
     UNION ALL
     SELECT 10 AS a, NULL AS b
) t

-- нужно получить
-- | a | b |
-- | 1 | 5 |
-- | 5 | 8 |
-- | 8 | 10 |
-- | 10 | null |

тут нейронка нужна, только нейросеть может угадать что хотел автор от давая на вход 42 и получая на выходе 111113

диапазоны что-ли надо склеить? или что? или дерево развернуть наружу?

данные в from менять нельзя?)

Нет

SELECT *
FROM (
     SELECT 1 AS a, 5 AS b
     UNION ALL
     SELECT 2 AS a, 5 AS b
     UNION ALL
     SELECT 3 AS a, 6 AS b
     UNION ALL
     SELECT 4 AS a, 7 AS b
     UNION ALL
     SELECT 5 AS a, 8 AS b
     UNION ALL
     SELECT 6 AS a, 9 AS b
     UNION ALL
     SELECT 7 AS a, 10 AS b
     UNION ALL
     SELECT 8 AS a, 10 AS b
     UNION ALL
     SELECT 9 AS a, NULL AS b
     UNION ALL
     SELECT 10 AS a, NULL AS b
) t where t.a in (1, 5, 8, 10) order by t.a

Вообще задачу слабо понял)

условию удовлетворяет, но вряд ли хотели именно этого))

похоже что asof пока умеет только hash

2. в смысле параллелятся вообще джойны плохо

https://gist.github.com/den-crane/2e7bb5927d8f1b435da890ae90065990

Добрый день, arrayCompact + flatten не работает или не правильно использую? select arrayCompact(flatten([['a', 'b', 'c'], ['b'], ['c'], ['a', 'b']]));
Не удаляет дубли
Версия 19.17.9.60

arrayCompact про последовательные дубли

SELECT arrayDistinct(flatten([['a', 'b', 'c'], ['b'], ['c'], ['a', 'b']])) AS x

┌─x─────────────┐
│ ['a','b','c'] │
└───────────────┘

блииин, ну кто так доку перевел на русский, чудики

Спасибо! А то описание ввело в заблуждение

щаз исправим

Спасибо, а где можно все же про распараллеливание джойнов в СН почитать (не asof, а любых hash join)? Грузит ли все ядра при джойне двух больших таблиц (или подзапросов)?
Понимает ли, что при совпадающих партиционных ключах в условии, можно попартиционно джойнить, а не все на все?

нигде, можно у автора спросить @chertus

Спасибо! Сурово)

Вот только что наткнулся на то, что два inner joinа не все ядра задействуют

Интересно. Сколько удалось загрузить? И сколько есть всего?

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

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

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