cleanup_delay_period_random_add │ 10    │       0 │ Add uniformly distributed value from 0 to x seconds to cleanup_delay_period to avoid thundering herd effect and subsequent DoS of ZooKeeper in case of very large number of tables. │ UInt64

Подскажите, пожалуйста. Вот такая ошибка при вставке JSON по сети

Unknown field found while parsing JSONEachRow format: field_set.name[0]

Однако когда вставляю руками в ту же таблицу через клиент, все норм. Куда копать, ткните носом, пожалуйста. Используются Nested массивы

у меня есть некоторая гипотеза. Я не особо ориентируюсь в коде CH, но нашел вот такое, в бранче версии 20.6
https://github.com/ClickHouse/ClickHouse/blob/20.6/src/Storages/MergeTree/ReplicatedMergeTreeCleanupThread.cpp
327 строка
/// Use ZooKeeper's first node (last according to time) timestamp as "current" time.

   Int64 current_time = timed_blocks.front().ctime;

я смог это воспроизвести, при той же настройке, когда window_seconds=1

время считается (как я понимаю) не относительно текущего астрономического, а относительно времени последнего вставленного блока. Это означает, что если блоки были вставлены плотно по времени друг к другу (между ними было менее window_sec) то они не будут удалены никогда, до тех пор, пока кто-то не запишет еще один блок

не, походу этот поток вообще не запускается пока мердж не пройдет )

т.е. я вставил одну строку, и вставлял до посинения, она не вставилась...

возможно и это. Но вот сценарий, когда я провоцирую удаление вставив через некоторое время еще 1 блок, у меня сработал

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

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

все можно репортить, один китаец недавно 4 раза спросил когда уже Grace Join сделаете
заведите баг

Добрый день. Подскажите, ASOF JOIN может работать с подзапросами?

Добрый вечер еще раз.
левая таблица большая(700кк), справа два справочника(45к, 300 строк).
к первому по двум столбцам any left join (по дате и  ид), ко второму по ид. Проблема в производительности.
Нужно это для того, чтобы если из первого справочника совпадений не найдено, то во втором точно будут. Это все для coalesce в select.
DJ пытался мне помочь(select tableft join (select t1 join t2 on t1.id=t2.id)), но, к сожалению, это не помогает, потому что соединение левой и правой части должно быть по 2 полям(чтобы совместить дату и ид.)
Мб есть какие-то еще варианты?
Примерный вид запроса такой:
select t.val, coalesce(t1.val1, t2.val2) from t
any left join t1 on t.date=t1.date and t.id=t1.id
any left join t2 on t.id=t2.id

20.1.3.7 <--- это реально очень сырая версия , которая умеет портить первичный индекс. 20.1.16.120 -- последняя в 20.1

select tval, coalesce(t1val1, t2.val2) 
from   (select t.val tval, t1.val t1val1, t.id tid
            from t any left join t1 on t.date=t1.date and t.id=t1.id) z
any left join t2 on tid=t2.id

эх, к сожалению перепробовал много различных вариантов, пока не устраивает. Иногда падает по памяти еще такая штука.

ап версий пока на начальном тесте еще

покажите строку со статистикой моего варианта и вашего

я про апгрейд в последнюю минорную в вашем же 20.1 релизе (там только багфиксы)