DC
Этот вопрос из-за того, что смутила фраза в документации " При чтении будут использованы индексы тех таблиц, из которых реально идёт чтение, если они существуют "
имеется в виду что если индекс есть подходящий, он будет использован
Size: a a a
2019 December 05
DC
Кстати с merge не работает optimize_move_to_prewhere (надо писать prewhere вручную)
BB
Кстати с merge не работает optimize_move_to_prewhere (надо писать prewhere вручную)
Благодарю!
Z
Добрый день! Подскажите, пожалуйста, можно ли как то решить проблему с ограничением для даты: Range of values in the Unix timestamp: [1970-01-01 00:00:00, 2105-12-31 23:59:59].? Есть даты (дата рождения и пр.), которые меньше 1970 года и при этом нужно сохранить тип дата, положить в string нам не подходит(
D
Мы Int64 таймстемпы сохраняем
AS
Всем привет, сталкивался кто-нибудь с таким поведение: есть две таблицы, обычный ReplicatedMergeTree и AggregatingReplicatedMergeTree, связаны через MV. Данные перетекают из первой во вторую, все ок. Но в некоторые моменты (похоже на мержи) данные за последний час (время до часа округляется) перепрыгивают в 00:00:00, в итоге первый час постепенно растет, а последующие как получится. Что-то не пойму куда копать. Версия 19.17.4.11
AS
Время каждой новой записи >= предыдущей
спустя некоторое время
это уже в отдельной, свеже созданной таблице, т.е. воспроизводится. Смотрел данные, все корректно со значением времени.
┌──────────────────ts─┬─────X─┐
│ 2019-12-05 06:00:00 │ 42360 │
│ 2019-12-05 07:00:00 │ 4824 │
└─────────────────────┴───────┘
спустя некоторое время
┌──────────────────ts─┬─────X─┐
│ 2019-12-05 06:00:00 │ 43428 │
│ 2019-12-05 07:00:00 │ 5052 │
└─────────────────────┴───────┘
это уже в отдельной, свеже созданной таблице, т.е. воспроизводится. Смотрел данные, все корректно со значением времени.
AG
Время каждой новой записи >= предыдущей
спустя некоторое время
это уже в отдельной, свеже созданной таблице, т.е. воспроизводится. Смотрел данные, все корректно со значением времени.
┌──────────────────ts─┬─────X─┐
│ 2019-12-05 06:00:00 │ 42360 │
│ 2019-12-05 07:00:00 │ 4824 │
└─────────────────────┴───────┘
спустя некоторое время
┌──────────────────ts─┬─────X─┐
│ 2019-12-05 06:00:00 │ 43428 │
│ 2019-12-05 07:00:00 │ 5052 │
└─────────────────────┴───────┘
это уже в отдельной, свеже созданной таблице, т.е. воспроизводится. Смотрел данные, все корректно со значением времени.
Если имелось ввиду перепрыгивают в 00:00, то проверьте часовой пояс серверов и clickhouse-server, если сервера разные
AS
UTC, это смотрел, на примере выше перепрыгивает в 6 часов (так как значений раньше нет) и если бы были проблемы с поясом то прыгало на оффсет максимум, а тут с текущего в первый в пределах партишена
AS
причем если перелить партишен целиком, все ок 😕
AS
полностью воспроизвелось на другом инсте, в гисте SQL и все ответы Clickhouse
AS
тчерт =( таки сам дурак, забыл в order by вложить ts, вот он и схлопывает
A
Ребят, а flush_interval_milliseconds для query_log/part_log применяется без рестарта?
SS
Всем привет! Пробую CollapsingMergeTree - у меня он совсем ничего не схлопывает. Есть исходная строка с id = 1 и sign = 1. Затем, добавляю сторно строку с id = 1 и sign = -1 и сразу же новую строку id = 1 и sign = 1. Но я еще не видел, чтобы исходная и сторнирующая строки схлопнулись (сами) за несколько дней. Естесственно, помогает select ... final и optimize ... final и group by id можно использовать. Но хотелось бы без final обойтись. Версия 19.13.1.11
AM
Sergey Safonov
Всем привет! Пробую CollapsingMergeTree - у меня он совсем ничего не схлопывает. Есть исходная строка с id = 1 и sign = 1. Затем, добавляю сторно строку с id = 1 и sign = -1 и сразу же новую строку id = 1 и sign = 1. Но я еще не видел, чтобы исходная и сторнирующая строки схлопнулись (сами) за несколько дней. Естесственно, помогает select ... final и optimize ... final и group by id можно использовать. Но хотелось бы без final обойтись. Версия 19.13.1.11
HAVING SUM(flag) > 0
AM
а блин, не увидел про group by
SS
я про то, что обещанное схлопывание не происходит
OD
Всем привет!
Помогите разобраться пожалуйста, почему такой баг
https://github.com/ClickHouse/ClickHouse/issues/8030
Помогите разобраться пожалуйста, почему такой баг
https://github.com/ClickHouse/ClickHouse/issues/8030
G
Всем привет! Ни кто случайно не пробовал коннектиться из qlik к базе КХ? Вроде как это можно сделать через ODBC, но пока не получается разобраться как именно ^_^