Да, именно.
Нет, не DISTRIBUTED.

Поверх таблицы, куда вставляются данные, есть несколько MV с AggregatingMergeTree (вычисляю HIGH, LOW, OPEN, CLOSE на нескольких таймфреймах). Данные поступают интенсивно, но в батчах от 1000 строк (биржевые данные).

А несколькочасовая задержка - она про появление вставленных данных в AggregatingMergeTree таблицах? В базовой (исходной) таблице данные сразу появляются?

И там, и там. В исходной таблице данные также "отстают" на SELECT-ах и на примерно такой же интервал времени.

Я вчера (видимо, зря) создавал MV с POPULATE (хотел попробовать). Не знаю, связано это было с этим или нет, но через 6-8 часов появились вот эти задержки. Тот вью я грохнул и создал без POPULATE.

В логах в целом нормальная ситуация? Спама ошибок нет?

Ошибок нет.
В каждую секунду много сообщений типа removing part from filesystem, резервирования на диске, мерж кусков.

Добрый день. Например, в документации есть настройка MergeTree таблицы enable_mixed_granularity_parts, там не сказано ее дефолтное значение, поэтому я хочу посмотреть какое актуальное для нее значение у уже существующей таблицы. Есть ли какой то способ это сделать типа SHOW SETTINGS table?

SELECT * FROM system.merge_tree_settings WHERE name LIKE '%mixed_granularity%';

Ага, т.е. чтобы получить актуальные настройки таблицы, надо сравнить вывод SHOW CREATE TABLE секция SETTINGS, и если там не было значения, взять его из дефолта из system.merge_tree_settings?

Похоже что да, спасибо!

Либо system.replicated_merge_tree_settings для RMT таблиц
"Allow user to specify settings for ReplicatedMergeTree* storage in <replicated_merge_tree> section of config file. It works similarly to <merge_tree> section. For ReplicatedMergeTree* storages settings from <merge_tree> and <replicated_merge_tree> are applied together, but settings from <replicated_merge_tree> has higher priority. Added system.replicated_merge_tree_settings table. #13573 (Amos Bird)."

Я пас:(
Почему в исходной таблице с такой большой задержкой успешно вставленные данные не доступны в запросах, только 1 возможность приходит в голову - перегруженная асинхронная вставка в distributed, когда он сильно не успевает шардировать по кластеру. Но это не ваш случай.

Если бы были бы проблемы с самой вставкой (типа слишком большого числа партов), то это проявилось бы в логе (да и INSERTы кажется ошибку выдают в таком случае). Но если в базовую таблицу вставились, мелкий part от вставки образовался - то в SELECTе должно быть видно.

Ребят, какой best practice для перевода таблицы из одного типа партиции в другой?, допустим хочу одну таблицу перевести с помесячного партицирования на понедельную, нельзя это сделать налету? без пересоздания таблицы и перекидывания кучи данных

Здрасте, были у кого-то проблемы с tcpшным go драйвером и pingом?
А именно то, что для read-only пользователя эта операция недоступна?

Хм, оно даже SELECT 1 не дает сделать из под ro-юзера, интересно, ЧЯДНТ🤨

парты с toyyyymm назваются короче. в зк места меньше занимают

Да нет конечно.
Партиционирование вообще не влияет на это.
В mrk хранятся 2 64 битных смещенения для каждой гранулы
В mrk2 2 64 + 64 бит размер гранулы

Ошибка-то какая? Возможно он settings передает

ну само то значение тоже в mrk хранится. разве нет?