А, ну и скорее всего будь у вас условие WHERE user_id IN
то GROUP BY будет быстрее

Всем привет, движок merge tree логически использует в итоге дерево? Я к сожалению не смог найти документального подтверждения этому, может у кого-то есть статья про это?

Вопрос: а какой репортинг тестов ClickHouse на github использует? Check Runner Report ?

Еще есть вопрос про View. В документации написано, что это всего лишь сохраненные sql запросы.
Если я создал

CREATE VIEW v as SELECT * from t

а потом делаю

SELECT col1, col2 FROM v WHERE col3 = '...'

то оптимизатор поймет что мне не нужно в память выгружать все колонки? А только col1, col2 и col3?

CREATE VIEW v as SELECT * from t

SELECT col1, col2 FROM v WHERE col3 = '...'

Колонки - Да, но насколько я знаю предикаты не пробрасывались.

добрый день!

такая беда
0. ставлю max_insert_threads = 6
1. делаю select-insert большой таблицы (на самом деле партиции: я переношу огромную таблицу по партициям)
2. оно показывает какое-то фантастическое rows/s
3. и через пару минут падает с Too many parts
4. но зато если не падает (например, если поставить max_insert_threads поменьше, или просто если повезёт), то со временем rows/s становится совсем маленький, и всё очень долго

есть какой-то механизм (само)регуляции, чтобы КХ не пытался отправлять больше, чем он может обработать?
например, какой-нибудь многоступенчатый parts_to_delay_insert
то есть я понимаю, что в общем случае надо, наверное, подбирать параметры parts_to_throw_insert и parts_to_delay_insert под нагрузку
но как быть, когда эту нагрузку генерирует сам КХ?

может, для инсерт-селектов есть какое-то специальное решение?

Вчера переливал таблицу с 800 миллионами строк из одного КХ в другой - без проблем за 15 минут залилось.
too many parts обычно возникают, если ключ партиционирования неудачно подобран.
Обычно хватает вот такого: PARTITION BY toYYYYMM(Date)

добрый день, коллеги/саппорт
кто нибудь сталкивался с проблемой, что КХ перестал удалять данные?
запросы вида alter table {NAME} delete where {COND} обрабатываются без ошибок, но по факту данные не удаляются. с readonly всё ок (в смысле прав у пользователя хватает), остальные операции работают без проблем

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

у меня некоторые партиции тоже иногда без проблем льются (в партиции 35 млрд записей)
но оставить на ночь нельзя, потому что может упасть, а может не упасть
в целом эвристика такая, что если за 10 минут не упало, то следующие 2 часа всё будет хорошо

А движок таблицы какой? MergeTree?
Помню тут читал, что в этом случае происходят фоновые слияния, но старые файлы остаются еще 8 минут до их полного убиения. Можно попробовать сократить время жизни этих файлов до одной минуты на время массовой заливки, а потом вернуть взад...

Всем привет! Подскажите, пожалуйста, почему разница выходит ноль при следующем запросе

SELECT toDateTime('2019-08-31 20:35:00', 'UTC') as a ,
      toTimeZone(toDateTime('2019-08-31 20:35:00'), 'Europe/Moscow') as b,
      dateDiff('hour', a, b)  AS diff;

потому что вычитаются два одинаковых таймстемпа?

можно приподнять лимиты на кол-во партов

у меня разница вообще 2 часа

тут все зависит от таймзоны сервера

Ну это же очевидно баг

сервер в зоне gmt +3

Дерево в том смысле если нарисовать историю мержей то она похожа иерархическая.

При выполнении запроса даты высчитываются корректно (ко второй прибавляется 3 часа), однако разница равна 0

select timezone()