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

сделайте через send_logs_level='debug'
заодно проверите сколько он ест памяти в обоих вариантах...

да, это обязательно попробую

Приветствую. Столкнулся с проблемой невозможности использования глобального подзапроса в локальном. Есть ли какая-нибудь возможность для исполнения подобного сценария?

а какую ошибку показывает?
выглядит так что просто побоялись беспонечных циклических подзапросов из GLOBAL IN получить...

Love the to_dict() addition

DB::Exception: Double-distributed IN/JOIN subqueries is denied (distributed_product_mode = 'deny'). You may rewrite query to use local tables in subqueries, or use GLOBAL keyword, or set distributed_product_mode to suitable value. (version 19.14.11.16 (official build))

если поменять на локальную, то всё ок. Но в реальном решении это не подходит, так как нужны данные из поля не по ключу шардирования.

Он же в ошибке пишет что нужно сделать, чтобы разрешить.

замените везде IN на GLOBAL IN

но производительность замедлится и нагрузка на CPU на ноде инициаторе запроса возрастет

да, этот вариант работает) Но хотелось бы как я описал

да да, замедлится

ну как вариант сделать Table3 - словарем
и вытащить через WHERE dictGet

всем привет, проблема при переключении на новый КХ 20.5.4.40. Перенес данные со старой версии 19.3.5 в новый, пересоздал таблицы в новом формате, поменял c

ENGINE = MergeTree(EventDate, (View, Click, Get, EventDate), 8192)

на

ENGINE = MergeTree
PARTITION BY toYYYYMM(EventDate)
ORDER BY (View, Click, Get, EventDate)

но при переключении приложения на новый КХ почему-то в некоторых колонках значения получаются очень большие

это нормальные значения на старом КХ

┌──────────────g_date─┬─────profit─┐
│ 2020-08-14 01:25:00 │ 1.06384226 │
│ 2020-08-14 01:26:00 │ 1.14885028 │
│ 2020-08-14 01:27:00 │ 1.06182347 │
│ 2020-08-14 01:28:00 │ 0.03494053 │
│ 2020-08-14 01:29:00 │ 0.25599383 │
└─────────────────────┴────────────┘

а это на новом

┌──────────────g_date─┬───────profit─┐
│ 2020-08-14 01:27:00 │   0.02914438 │
│ 2020-08-14 01:28:00 │ 215.75539282 │
│ 2020-08-14 01:29:00 │ 172.57422046 │
└─────────────────────┴──────────────┘

в чем может быть проблема с новым КХ?

ENGINE = MergeTree(EventDate, (View, Click, Get, EventDate), 8192)

ENGINE = MergeTree
PARTITION BY toYYYYMM(EventDate)
ORDER BY (View, Click, Get, EventDate)

┌──────────────g_date─┬─────profit─┐
│ 2020-08-14 01:25:00 │ 1.06384226 │
│ 2020-08-14 01:26:00 │ 1.14885028 │
│ 2020-08-14 01:27:00 │ 1.06182347 │
│ 2020-08-14 01:28:00 │ 0.03494053 │
│ 2020-08-14 01:29:00 │ 0.25599383 │
└─────────────────────┴────────────┘

┌──────────────g_date─┬───────profit─┐
│ 2020-08-14 01:27:00 │   0.02914438 │
│ 2020-08-14 01:28:00 │ 215.75539282 │
│ 2020-08-14 01:29:00 │ 172.57422046 │
└─────────────────────┴──────────────┘

сначала сравните сырые данные между старым и новым (count). совпадают ли они?

при переносе данных count совпадал

ну тогда, последовательно упрощайте запрос и сравнивайте. там вообще много чего поменялось за это время...

Друзья, привет
Есть ли у кого-то опыт пролива flyway с помощью docker на Clickhouse?
Применение популярного тут ПР https://github.com/flyway/flyway/pull/2640

Реквест уже успел протухнуть. Они поменяли внутреннее api.