(последнюю это в смысле последнюю вставленную, из номера парта вычислено будет)

Спасибо. Я обратила внимание на то, что у нас есть дубликаты, хотя по доке получается, что их не должно быть.
Вероятно, не было слияния в определенных партах.

да слияния, и создатель движка предполагал что будут использоваться <function>any или max и тогда в запросах дубликаты не будут влиять на результат

Всем привет! А можно как-то загружать pandas dataframe в clickhouse?

Привет! Можно ли как-то сказать clickhouse-у чтобы он больше ресурсов тратил на optimize table final?

По партициям в aggregatingmergetree должно быть 100. После интенсивной вставки осталось ~2500 партов. Процесс optimise table final висит, но ресурсы особо не тратит. Сервер стоит ничего толком не делает. В логе мержи идут, но процессоры не заняты практически - пара ядер из 32-х

Как-то весь процесс встрял на optimize в итоге. Group by не влезает ни в какую память, а optimize как-то не торопится мержить

Всем привет!
Подскажите, будет ли корректно работать вьюха, в которой таблица джойнится  на себя саму?

В таблице есть три уровня грануляции: дата, наименование события и id сессии. Для агрегации даты используется minState, событий -- CountState.

Таблица будет джойнится с агрегатом, где высчитывается дата начала сессии minMerge. Потом объединенная таблица агрегируется по названию события и дате начала сессии. Считается кол-во событий при помощи countMerge.

Или лучше все это грузить в array, группировать по сессиям, сортировать и выводить первое значение  в качестве даты начала сессии?

background pool size увеличьте

какие значения приемлемы? сервер 32 процессора 128 гб памяти

неважно кто куда джойнится, но условия во вьюху не прокинуться вроде (хотя тут по чатику стоит поискать, может уже что-то сделано)

если надо побыстрее все промерджить и можно забить на запросы, ставьте в 32 =) а вообще по умолчанию 16

Спасибо

понял, спасибо

вы сначала посмотрите в system.merges,может у вас система чем-то другим занята?

не, только эта таблица и есть

ну, тогда ставьте в 32 если уверены что вы уперлись в СПУ... просто есть ненулевая вероятность что вы уперлись в диск

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

Ну ставьте 32 и вперед.