294
SELECT count(DISTINCT ip) as num FROM stats WHERE link_id = '159' AND toYYYYMMDD(created_at) = '20200101' GROUP BY toHour(created_at)

277
SELECT count(DISTINCT ip) as num FROM stats WHERE link_id = '159' AND toYYYYMMDD(created_at) = '20200101'

делается же GROUP BY toHour() значит в первом случае один и тот же айпи может быть посчитан дважды

А.. логично. Спасибо

Доклад про фазинг в ClickHouse:
https://youtu.be/GbmK84ZwSeI?t=4481
Слайды: https://presentations.clickhouse.tech/cpp_siberia_2021/

му они должны были растаять

Круто, интересно, спасибо! Только возникает вопрос: зачем их запускать на каждом пулл реквесте, а не запускать периодически/постоянно отдельно и потом ассоциировать баги со старыми мерджами. Фаззер на пулл реквесте, вроде, с намного большей вероятностью найдет ошибку в коде, не связанном с этим пулл реквестом, и она будет потеряна, при этом успев напугать/раздражить автора.

1. У фазера включена агрессивная проверка запросов из новых тестов. То есть, он в первую очередь проверяет как раз то, что добавлено в PR.

2. Мы думаем, что скоро закроем все найденные проблемы, а новые в старом коде будут находиться редко: https://github.com/ClickHouse/ClickHouse/issues?q=is%3Aissue+is%3Aopen+label%3Afuzz

OK. А как отслеживаются несвязанные (промежуточные) фейлы в PR-ах?

Пока просто каждый фейл отсматриваем вручную.

Вечер добрый коллеги!
Подскажи те кто то знает про директорию moving ? что то в документации не могу ничего найти.

Коллеги, подскажите пожалуйста по оконным функциям (включена экспериментальная поддержка в версии 21.3.1.6060):
можно ли (и если да - то как) заставить КХ возвращать не дефолтное значение колонки (в моем случае возвращает 0),
а NULL, в случае когда не найден определенный лаг в группировке?

пример:
для target = [16, 15, 14],  отсортированных по убыванию времени (т.е. от новых к старым наблюдениям)

any(target) over (partition by ... order by time_slot asc rows between 1 PRECEDING and 1 PRECEDING) as target_last_observed,
any(target) over (partition by ... order by time_slot asc range between 300 PRECEDING and 1 PRECEDING) as target_lag_1,

возвращают столбцы
target_last_observed = [15, 14, 0]
и  target_lag_1 = [15, 0, 0] (т.к. есть пропущенный 5минутный интервал)

хотелось бы получить [15, 14, null] + [15, null, null], чтоб отличать настоящий ноль от пропущенных значений

any(target) over (partition by ... order by time_slot asc rows between 1 PRECEDING and 1 PRECEDING) as target_last_observed,
any(target) over (partition by ... order by time_slot asc range between 300 PRECEDING and 1 PRECEDING) as target_lag_1,

aggregate_functions_null_for_empty=1

класс, это в конфиге сервера зафиксировать можно?

да, в профиле пользователя

большое спасибо!

любые настройки которые через set (это параметры сессии) можно включить в профиле пользователя

aggregate_functions_null_for_empty выключена по умолчанию чтобы не создавать nullable где они не нужны и не портить перфоманс

👍

а ну и для обратной совместимости, это новый параметр

Добрый день.
Есть таблица с TTL для переноса партиций на более медленный диск через 1 месяц.
Заметили странное накомление данных на исходном диске в каталоге
/var/lib/clickhouse/data/default/TABLENAME/moving
Причём эти данные не фигурируют в записях system.parts.

Как удостовериться, что данные перемещаются на другой диск корректно?
Для чего используется этот каталог moving? Судя по логам - как место для копии pertition перед перемещением, а зачем?
Как безопасно очистить moving каталог таблицы?

Есть пример summap для нескольких столбцов.