та же проблема, оно у вас решилось?

https://github.com/ClickHouse/ClickHouse/issues/13861
нашел это

Кто-нибудь сталкивался с ошибкой Table was not dropped because ZooKeeper session has expired? Как её можно обойти? Удаление на конкретном хосте не помогло

надо лог КХ смотреть на том хосте и лог зукипера

можно просто сделать detach table ... , удалить файлы на диске и ветку реплики в zk

Можно,
select * from system.graphite_retentions, мы так узнали,  что сломали ретеншены

охх благодарю, попробую сейчас

@den_crane а вы можете теги в ишщях выставлять? просто https://github.com/ClickHouse/ClickHouse/issues/13861 это баг. BW compatibility тут не причем. При создании словаря на odbc с нуля так же не работает...

Привет, подскажите пожалуйста, насколько важно для производительности select запросов в первичный ключ таблицы вставлять поле по которому часто происходит группировка (кортеж из нескольких полей) ? По партициям таблица разбита с учётом условий частых запросов, тут все ок. А вот как определять order by() для будущих группировок не очень понятно.

ну вот совсем недавно запили оптимизацию group by с использованием PK индекса.
https://github.com/ClickHouse/ClickHouse/pull/9113
>По партициям таблица разбита с учётом условий частых запросов, тут все ок
эх

А не подскажете, вот эти дефолтные age и precision распространяются на правила с паттернами? Я в дефолтах определил лишь age+precision чтоб не повторять для каждого паттерна, боюсь что ничего теперь не роллапится что не попадает под паттерны.

в PK лучше вставлять то, что наибольшим образом отсекает лишние parts через условия WHERE  ;)
например время
и поля с низкой кардинальностью которые учавствуют в большинстве запросов (event_type типично)

PARTITIONS (не путать с parts) тоже не должно быть слишком МНОГО

очень грубо говоря
сначала через WHERE определяются какие PARTITIONS будут участвовать в запросе
потом сканируется каждый part в каждой партиции (паралельно), читается (с кешированием) .mrk файл в котором значения полей из PK в соответствии с index granularity   и по значениям полей из PK которые учавствуют в запросе определяется надо ли делать полное сканирование для этого part или нет
и уже потом идет распаковка поточная .bin файлов с данными и их сканирование

производительность GROUP BY
зависит больше от того насколько много уникальных комбинаций значений полей из GROUP BY у вас на выходе получается
потому что аггрегатная функция по сути своей формирует хеш таблицу ключ у которой это уникальная комбинация из GROUP BY ... а значения это структура из необходимых полей которые нужны для конкретной аггрегатной функции

странная какая то оптимизация на первый взгляд

Спасибо за ответ! Да про partitions и parts все так, под частые условия и проектировались, при чем с учётом того, чтобы partitions не получилось слишком много. Про group by примерно понял

Ну и еще GROUP BY конечно зависит от того насколько много строк у вас БЕЗ GROUP BY
то есть запрос в котором 1 миллион строк превращается в 1000 через GROUP BY
будет скорее всего быстрее чем запрос в 10 миллионов строк которые превращаются в 100

да ниче ок, Elapsed: 36.085 sec VS Elapsed: 0.078 sec.

create table GT( A Int64, B Float64) Engine=MergeTree order by A;

insert into GT select number%55555555, 0 from numbers (1000000000);

set max_threads=1;
select sum(B), A from GT group by A limit 3;

3 rows in set. Elapsed: 36.085 sec. Processed 1.00 billion rows

set optimize_aggregation_in_order=1;

select sum(B), A from GT group by A limit 3;
3 rows in set. Elapsed: 0.078 sec. Processed 4.47 million rows

Никак, это дефолт,  то есть то,  что не подходит под паттерны,  в паттернах задайте свои age,  precision

Мы,  например до 48 часов ничего не делаем (не прореживаем),  а после прореживаем до 1 точки в минуту,  затем,  после 90 дней -  до 1 точки в 10 минут и партиции недельнык падают с 300гб до 30

привет! у меня вопрос про STOP MERGES
1) реплицируемый ли это запрос, или надо на всех хостах выполнять?
2) можно ли как-то проверить, что для таблицы мержи включены/выключены? или только очередь system.merges?
задача - отключить мерж временных таблиц, чтоб не тратить зря ресурс

1 на всех
2 никак

>задача - отключить мерж временных таблиц, чтоб не тратить зря ресурс
все это звучит исключительно дико со всех точек зрения, примерно как попытка выстрелить в оба колена сразу
эээ каких временных ? движок?   MergeTree ? ну так вставляйте чтобы был сразу один парт и никаких мержей не будет.