Рублю большой батч из-за ограничений на число партиций в инсерте. Какую паузу в таком случае стоит взять между вставками?

ну вообще в чятике советуют раз в секунду жирный батч вставлять)

Странно, вроде бы секундная пауза между вставками есть. Буду разбираться.

а как таблица партиционирована ?

Остаток от деления одного из группирующих id на 1000

какая версия кх?
Вообще это не оч хороший ключ обычно
Зачем такой сделан?

возможно из-за этого проблемка с ошибкой на вставку из-за количества партиций в инсерте

20.6.3.28
Это эксперимент, для проверки гипотезы. Я здесь только организую поток данных в CH. Есть какие-то проблемы с производительностью SELECT при партиционировании по дате.

вообще лучше подняться хотя бы до 20.8 версии

> Есть какие-то проблемы с производительностью SELECT при партиционировании по дате.
Показывайте партиционирование и запросы которые тормозят

%1000 сделает только хуже в вашей версии, он вообще не будет работать

А эта ошибка следит за каким-то глобальным параметром для всех таблиц или для каждой таблицы по отдельности?

Для каждой таблицы

Постараюсь добыть и вернуться с запросами.

Таблица примерно такая

(
    `clickhouse_partition_date` Date,
    `id` UInt32,
    `type_id` UInt8,
    `group_id` UInt32 COMMENT 'Идентификатор филиала.',
    `version` DateTime COMMENT 'Версия строки.',
    `other_date` Date,
    ...
 )
ENGINE = ReplacingMergeTree(version)
PARTITION BY toYYYYMM(clickhouse_partition_date)
ORDER BY (group_id, type_id, id)

Запросы с группировкой по group_id и other_date за определённый промежуток. Коллег смущает, что не могут использовать выборку в рамках партиций из-за необходимости использовать там статичную дату для схлопывания строк в рамках ReplacingMergeTree. other_date может меняться периодически.
Мои доводы про то, что group_id  уже является частью первичного ключа, они не хотят воспринимать.

(
    `clickhouse_partition_date` Date,
    `id` UInt32,
    `type_id` UInt8,
    `group_id` UInt32 COMMENT 'Идентификатор филиала.',
    `version` DateTime COMMENT 'Версия строки.',
    `other_date` Date,
    ...
 )
ENGINE = ReplacingMergeTree(version)
PARTITION BY toYYYYMM(clickhouse_partition_date)
ORDER BY (group_id, type_id, id)

В чем идея специальной даты для партиционирования?
clickhouse_partition_date

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

В общем в ключе партиционирования вы должны использовать туже дату/datetime что и в запросах, тогда сработает partition prunning

Тогда возникает проблема:
Допустим мы вставили строку с 31.01.XXXX для данных.
Затем эти данные изменились, вставляем новую строку с 01.02.XXXX свежими данными и более новой версией.
Соответственно мы получим задвоение данных, они появятся в том числе при выборке за Январь.

Добрый день, коллеги
Вижу в https://clickhouse.tech/docs/ru/whats-new/changelog/
Added PostgreSQL table engine (both select/insert, with support for multidimensional arrays), also as table function. Added PostgreSQL dictionary source. Added PostgreSQL database engine. #18554 (Kseniia Sumarokova).
Это аналогично MySQL Dataabse Engine позволяет использовать в SQL-оперциях таблицы Postgres без необходимости их импорта в словари?

(в документации пока не вижу)

То есть это очередной шаг (после импорта таблиц Postgres в словари и реализации Posgres Wire Protocol) в сторону интеграции ClickHouse & Postgres?

Да, но там сыровато чутка