🤔тогда в каких случаях CH может сразу выкидывать OK если запускается FINAL DEDUPLICATE, переодически делаю select на system.parts и вижу что записи по партиции схлопываются в одну

если не может начать мерж
это можно проверить  set optimize_throw_if_noop=1; OPTIMIZE TABLE mergeTreeDB FINAL DEDUPLICATE;

>переодически делаю select на system.parts и вижу что записи по партиции схлопываются в одну
мержи идут постоянно, каждый инсерт и каждые 3? сек. шедулер мержей запускает анализ, нужно мержить или нет

раз в день запускается джоб который батчами в течении часа-двух делает insert, после окончания джжобы запускается merge FINAL DEDUPLICATE. Где то он работает несколько минут, где то сразу выдает ok.
Я хочу быть уверенным что он отработал и думал что system.parts мне в этом поможет

ну как бы system.parts может показать сколько партов в партиции, если партов больше одного значит можно еще помержить.

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

Про какой движек кстати речь?

ReplicatedReplacingMergeTree

вам нужно запускать OPTIMIZE TABLE ... FINAL
DEDUPLICATE не для этого движка

не совсем понял

```OPTIMIZE применяется к таблицам семейства ReplicatedMergeTree, ClickHouse создаёт задачу на мёрж и ожидает её исполнения на всех узлах```@Doc

https://clickhouse.tech/docs/ru/sql-reference/statements/optimize/

Если указать DEDUPLICATE, то произойдет схлопывание полностью одинаковых строк (сравниваются значения во всех колонках), имеет смысл только для движка MergeTree.

тогда не понятно как оно работает на семейство ReplicatedMergeTree, тут оно то же схлопывается

да вообще не про это речь, при чем тут replicated

короче, у ваc ReplicatedReplacingMergeTree, вам надо запускать OPTIMIZE TABLE ... FINAL и только на одной из реплик в каждом шарде. точка.
DEDUPLICATE вам не нужен, он не применим к replacing

Может есть у кого идеи что/где посмотреть?
Первый в списке запрос обычно выполяется в пределах 1 секудны.

query_log включили, но что имеено ждал запрос непонятно:

['Query','SelectQuery','FileOpen','Seek','ReadBufferFromFileDescriptorRead','ReadBufferFromFileDescriptorReadBytes','ReadCompressedBytes','CompressedReadBufferBlocks','CompressedReadBufferBytes','IOBufferAllocs','IOBufferAllocBytes','ArenaAllocChunks','ArenaAllocBytes','FunctionExecute','MarkCacheHits','CreatedReadBufferOrdinary','DiskReadElapsedMicroseconds','SelectedParts','SelectedRanges','SelectedMarks','ContextLock','RWLockAcquiredReadLocks','RealTimeMicroseconds','UserTimeMicroseconds','SystemTimeMicroseconds','SoftPageFaults']
[1,1,306,342,1263,17480414,4080595,695,57656057,1371,30059123,403,1650688,5598,306,306,4000,12,105,430,985,20,266184321,172244,7671,5104]

['max_query_size','use_uncompressed_cache','load_balancing','log_queries','max_ast_elements','max_memory_usage']
['10000000','0','random','1','800000','20000000000']

спасибо большое :)
но у меня еще не вся мозайка собралась, похоже нужно курить исходник в гите

у replacing движка есть свойство, при мерже оставлять последнюю (или с макс. version) запись по ключу
он делает это по ключу order by
не важно кто запустил мерж и как
если вы запустите OPTIMIZE TABLE , то шедулер возьмет и запустит внеочередной мерж и хоть что-нибудь помержит
возьмет 2 парта из 30, сделает один, и уберет автоматически дубликаты ПО КЛЮЧУ
если запустить OPTIMIZE TABLE ... FINAL, просто будет мерж всего до упора пока можно мержить.
естественно это уберет автоматически дубликаты ПО КЛЮЧУ потому что так работает мерж для replacing


DEDUPLICATE -- это специальное свойство для простого движка MergeTree, там не убираются дубликаты при обычных мержах. DEDUPLICATE запускает специальный мерж который сравнивает все поля и убирает полные дублика строк, это нужно ТОЛЬКО для самого простого движка MergeTree, все остальные Replacing/Collapisng/Summing/........ всегда коллапсят записи сам, потому что так их движки заданы, они учитывают ключ ORDER BY при любых мержах

Супер!
Это нужно в доку!
Большой респект Вам!))

вы бы хоть array join cделали + формат vertical ниче не понять какой параметр для какого

Подскажите, а alter delete in partition с какой версии КХ есть/будет?

20.12

ok, спасибо

Добрый день. Подскажите по cache словарям, источник КХ. Что значит lifetime как время устаревания. То есть по проишествию lifetime данные очищаются из кэша? И что значит SIZE_IN_CELLS, как его можно примерно посчитать для своих таблиц?