по моей статисктике мутации успешно завершаются с вероятностью 50%. Поэтому это все бессмысленный разговор.

т.е. как-то это поправить толком не получится? всё перегуглил уже

а зачем это править? Какая разница что select показывает? Словарь не для этого

мне нужно чтоб ipv4 адреса отображались в нормальном привычном формате

абаждите, вы покажите проблему с dictGet

о, а с dictGet и правда норм работает, спасибо

> по моей статисктике мутации успешно завершаются с вероятностью 50%. Поэтому это все бессмысленный разговор.

а вот это интересно и неожиданно. возможно можете посоветовать как быть в таком случае?
имеется таблица с timeseries данными - показания датчиков. в нормальном режиме данные приходят в реальном времени, писать можем батчами раз в N секунд. но иногда с датчиков приходят выгрузки за определенный период и бизнес требования таковы, что все существующий данные по этому датчику за указанный период нужно заменить. т.е. не дописать строки, а все что есть удалить (или сделать недействительным), а после новые записать.
колич датчиков ~100K, input rate ~30K rows/sec. колич таких выгрузок 10-20 в день, т.е. это редкий случай и скорость их загрузки не имеет значения. именно для этого я думал о ALTER DELETE

Привет! А нет ли проблем у ReplacingMergeTree с optimize final? Заметил странное поведение. Внутри единстенной партиции есть 15 партов и optimize final ничего не делает(запрос просто завершается). За то если вызвать без final, то запрос что-то делает

А что вы хотите чтобы запрос сделал? Выдал ответ?

хочу чтобы он парты мержить начал)

У меня мерджит

в query_log вижу, что запрос завершается корректно

вопрос вдогонку про вероятность успешного выполнения 50%:
разве стандартное слияние партиций сделано не через мутации? как это работает если мутации то выполняются то нет? можете подробней рассказать что происходит с failed мутациями? они просто скипаются или происходит повторная попытка?

Добрый день.
Помогите пожалуйста решить проблему с ODBC.
Установлен и настроен ODBC-драйвер для PostgreSQL. Выполняем запрос через isql - всё отлично, всё работает.
Выполняем запрос в ClickHouse (через clickhouse-client) и получаем ошибку:

Code: 86. DB::Exception: Received from localhost:9000. DB::Exception: Received error from remote server /columns_info?connection_string=DSN....
HTTP status code: 500 Internal Server Error, body: Error getting columns from ODBC 'std::exception. Code: 1001, type: nanodbc::database_error, e.what() = ../contrib/nanodbc/nanodbc/nanodbc.cpp:4806: 08S0: SQLTables unable due to the connection lost  (version 21.5.5.12 (official build))'

Запрос простейший вида:
SELECT * FROM odbc('DSN=psql_dsn;', 'sometable') LIMIT 1;

Если же запрос изменить, добавив к DSN значения uid и password, т.е.
SELECT * FROM odbc('DSN=psql_dsn;uid=clickhouse;passwd=xxxxxx', 'sometable') LIMIT 1;

тоо всё работает!

Если выполнить рестарт clickhouse-server, то ошибка исчезает на какое-то время, а потом снова появляется. Закономерности пока никакой выявить не удалось.

Добрый день. Можно ли как то заставить ClickHouse создавать несколько материализованных преставлений параллельно? Я например запускаю создание 10 (все с populate) первый самое большое - занимает до 2ух минут и последней MV создается обычно за 1 сек.Так вот если я запустил создание сразу 10, то они похоже создаются по одному. Т.к тот что обычно занимает 1 сек ждет пока будут созданы все, которые были запущены на создание ранее.

привет
подскажите, пожалуйста, есть ли функция, которая добивает переданную строку нужным символом до определенной длины?
например, передали 40000, хочу добить нулям слева, чтобы получить строку длиной 6 символов, т.е. 040000
аналогично: 1000 -> 001000

repeat('0', 6- lenght(str)) || str

Но мб есть и другой враиант

Лучше не использовать POPULATE

Ок

postgresql движок вам не подходит по какой то причине?