show create table system.query_log

а вот там ТТЛ нет. т.е. мне ее дропнуть и тогда КХ создаст с нужным ТТЛ?

да

и там не в этой таблице поди проблема-то (с пожираемым местом), а metric_log

а это что за зверь?

ну лог метрик КХ

там таблиц вагон уже system.*_log

и все место жруть

и я бы конечно делал дневные партиции и ttl_only_drop_parts

<query_log>
       <database>system</database>
       <table>query_log</table>
       <engine>ENGINE = MergeTree PARTITION BY (event_date) ORDER BY (event_time) TTL  event_date + 1 day SETTINGS ttl_only_drop_parts=1 </engine>
       <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

Вот они - враги по desc:
system,query_thread_log_1,134620400113,125.38 GiB
system,query_thread_log_2,105903468273,98.63 GiB
system,query_log_2,91471687193,85.19 GiB
system,query_log_1,55670315998,51.85 GiB
system,query_log_0,45219397647,42.11 GiB

если таблицы не нужны то remove="1"

cat /etc/clickhouse-server/conf.d/z_log_disable.xml
<?xml version="1.0"?>
<yandex>
   <asynchronous_metric_log remove="1"/>
   <metric_log remove="1"/>
   <query_log remove="1"/>
   <query_thread_log remove="1"/>    
   <trace_log remove="1"/>
</yandex>

+restart CH

да, именно. Спасибо

query_log_2  query_log_1 query_log_0 -- это старые таблицы, после апргрейда

их можно дропнуть

если при старте КХ обнаруживаем что структура его _log таблицы неправильная (не хватает полей наприме), то КХ переименовывает таблицы _1 _2 _3

ок ))

Почему он мне не дает создать пользователя?

нужен пользователь с access_management

<?xml version="1.0" ?>
<yandex>
   <users>
       <default>
    <access_management>1</access_management>
       </default>
   </users>
</yandex>

Можно чуть-чуть больше деталей если не сложно? я чувствую что где-то мои интуитивные понятия об устройстве таблицы дают сбой:
Возьмем движок MergeTree. Есть структура таблицы - ее DDL. Есть мета таблицы - где какие данные лежат, иначе говоря system.parts.
Это верно?

Я представлял операции упрощенно примерно так:

Вся работа с system.parts через RW lock.

Инсерт - пишем файл(ы) в папку партиции(новые парты), добавляем запись в system.parts - движок может читать из этого парта.

Дроп партиции/партов - удаляем из system.parts(движок перестает читать из партов), удаляем из ФС(возможно не сразу, не важно).

Мерж партов - берем n партов, мержим на ФС, в system.parts удаляем старые парты, добавляем новый(е).

Мутация - частный случай мержа где n=1(ну, и логика фильтров/изменений).

SELECT из таблицы сначала идет в system.parts и выбирает мн-во подходящих партов, затем читает из этих партов.

конечно вообще ВСЕ не так.

почему мержи должны блокировать например удаление колонки -- никто не знает, включая разработчиков, в смысле надо сесть и полчаса вспоминать, соображать. Сейчас политика -- если мерж что-то блокирует отменяем мерж, делаем что-то, начинаем мерж заново, это внедрено для каких-то операций, типа drop table / drop partition, для каких-то нет.

никакие таблицы system не используются в этих местах

я тем более не могу ответить на этот вопрос, это только Сапин знает