5000 строк, 10 столбцов (внутри запроса суммирование, и другие обработки данных), в исходной таблице использующейся в запросе 100+ млн строк 80+ столбцов. Не кластер
2. Запрос отрабатывает за 30 секунд (это пока устраивает)
3. Если сделать таблицу и в неё произвести insert строк из запроса - работает 6+ минут.
3.1. Если сделать Live View то обновление её происходит за 6+ минут
3.2. Если сделать create table ... as select ... то те же 6+ минут
3.3. Если запрос за кинуть в словарь - те же 6+ минут
В чем может быть проблема?
ну смотря что за таблица конечная... какой движок? какой PARTITION BY ? но видимо у вас где то threadpool сдувается при трансформации ... попробуйте в clickhouse-client SET send_logs_level='trace'; SELECT ... ; CREATE TABLE ... AS SELECT... и посмотреть по логам в чем разница между SELECT и CREATE TABLE ... AS SELECT ...
Конечная таблица MergeTree (делал Memory то же самое), без партиций и с order by прикидывал по разному, итог 1 = 6+ минут
Посмотрел, когда создаю таблицу из select* from view - не используется MergeTreeInOrderSelectProcessor, если вытащить из view запрос - то все ок, ожидаемые 30 сек.
значит какая то бага в процессинге view судя по тому что тут https://github.com/ClickHouse/ClickHouse/issues?q=is%3Aissue+MergeTreeInOrderSelectProcessor ничего похожего на ваш баг не находится советую сделать issue в котором сделать простейший пример с одним полем и view и без view в котором сравнить скорость и использование MergeTreeInOrderSelectProcessor
Спасибо, уже делаю тестовый пример
Обсуждают сегодня