в query_log колонку memory_usage смотрю

21.3 просто точнее считает, 20.8 врал

так проблема в том, что с ограничением в 16гб, на 21.3 запрос не отрабатывает, а с этим же ограничением на 20.8 все отрабатывает

Привет! Подскажите есть кластер на 12 шардов с CH 20.1.4, в нем есть табличка, табличка на каждом шарде весит порядка 1Tb, она конечно ReplicatedMergeTree, нужно в нее добавить ALTER TABLE default.source ON CLUSTER cluster ADD COLUMN ip IPv4 AFTER id, вопрос такой какое дефолтное значение будет у домена IPv4, будет ли CH как то исторические данные заполнять или нет, и как быстро на таком кластере будет выполнятся данный запрос (в песочнице быстро, там данных очень мало и кластер на 2 машинки). Из документации не совсем понятно, данные очень чуствительны к потере, по этой причине и прошу совета у опытных.

а кто 16ГБ поставил?

И еще в документации есть ошибки к кому писать ?

в гитхаб в issue

ок

ADD COLUMN работает моментально если не наступит на merge
значение по дефолту 0000

я, руками, при увеличении лимата понятное дело на 21.3 отрабатывает тоже. Хотелось бы понять, по какой причине(опции) на 21.3 памяти требуется больше

21.3 просто точнее считает (учитывает больше мест где память на самом деле расходуется), 20.8 врал , вам конкретно строку кода показать и рассказать за 4 часа почему 20.8 неправильно считал память или что?

если бы вот этот PR замержили в 20.8 https://github.com/ClickHouse/ClickHouse/pull/16121
то 20.8 тоже бы показывал 17.26

Понял, спасибо!

Все как и сказали, спасибо!

Привет, подскажите пожалуйста, написал квери, чтоб сделать выборку по таблице с пятисекундным интервалом, таблица на 700кк строк, но в выборке существуют пробелы, не могу понять почему

INSERT INTO dest_table
SELECT
     *, runningDifferenceStartingWithFirstValue(Time) AS delta
FROM
(
    SELECT
        *
    FROM source_table
    WHERE Column = 'target_value'
    ORDER BY Time ASC
) where delta >= 5

Есть подозрение на данный ворнинг для функции runningDifferenceStartingWithFirstValue:
It can reach the previous row only inside the currently processed data block.
Т.е. мне кажется, что часть данных не попадает в блок и поэтому не процессится дельта по времени

Коллеги, добрый день!

FINAL DEDUPLICATE

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

FINAL DEDUPLICATE

про какой джвжок вопрос и про какие записи речь? одинаковые или что?

(но вообще если места нет на диске, то не гарантирует)

INSERT INTO dest_table
SELECT
     *, runningDifferenceStartingWithFirstValue(Time) AS delta
FROM
(
    SELECT
        *
    FROM source_table
    WHERE Column = 'target_value'
    ORDER BY Time ASC
) where delta >= 5

ну там в доке про runningDifference примеры есть, и как max_block_size влияет, можно просто увеличить max_block_size для проверки

у меня есть дубли, запускаю FINAL DEDUPLICATE, они мерджатся с этим все ок.
Эта задача я так понимаю(по нааблюдению) работает фоном и она асинхронная, хочу наблюдать через airflow за системной таблицей system.parts, что бы понимать схлопнулись дубли или еще нет

>Эта задача я так понимаю(по нааблюдению) работает фоном и она асинхронная
нет, не асинхронная

OPTIMIZE TABLE mergeTreeDB FINAL DEDUPLICATE

Ok.
0 rows in set. Elapsed: 21.380 sec.