Господа, а пробовал ли кто-нибудь менять TTL на materialized view? На самой вьюхе поменять нельзя, но зато получается поменять TTL для таблицы, которая хранит данные вьюхи (ну та, которая ".inner.view_name". Но самое забавное, что при этом SHOW CREATE TABLE мне показывает разные  TTL для вьюхи и .inner. таблицы. Кто знает, почему так и будет ли вообще такая схема работать?

будет. То что у MV написано используется только в момент create чтобы inner таблицу создать.
но поменять тоже можно и MV detach table / attach materialized view ENGINE..... TTL as select ...

Для того, что бы обновить индекс после добавления есть спец команда ALTER TABLE MATERIALIZE INDEX

Есть вопрос, по которому необходимо развеять сомнения. В КХ хранятся таблицы с одинаковой схемой данных для выполнения запросов с разным поисковым критерием по таблицам. Правильно ли я понимаю, что если хочется избавиться от дублирующей таблицы, то мне в данном случае необходимо создать индекс дополнительный и дропнуть дублирующую таблицу после создания индекса и исполнения optimize в оригинальной? В документации вроде бы написано, что можно создавать индекс, если критерий поисковой (условие запроса в WHERE) отличается (если я правильно улавливаю мысль)...

>дропнуть дублирующую таблицу после создания индекса
на всякий случай спрошу, вы понимаете что КХ не сам (автоматически) использует вторую таблицу и вы туда сами запросы пишете? И если ее дропнуть те запросы ошибку начнут возвращать?

Доброго времени суток! Можете подсказать, правильно ли я понимаю физический перенос данных КХ на другой диск?
1. Остановить запись + чтение из КХ
2. Остановить КХ
3. Переместить все из /var/lib/clickhouse (cores  data  flags  format_schemas  metadata  status  tmp  user_files) на другой диск
4. Поменять в /etc/clickhouse-server/config.xml <path> и <tmp_path> на диру с другого диска
5. Запустить КХ

да, правильно

всем привет, а не подскажите, как можно найти ближайшую дату?
например у меня есть одна таблица
created_date
2020-09-27 18:12:56 <—-1
2020-09-27 18:53:37 <—-2
и найти в другой ближайшую дату
created_date
2020-09-27 15:58:01
2020-09-27 15:58:10
2020-09-27 18:38:07 <—1
2020-09-27 18:38:34
2020-09-27 18:38:53 <—2
Спасибо

почему select в distributed поверх replicated работает медленнее чем запрос в саму replicated (при prefer_localhost_replica )? там что-то не пушдаунится?

Ребят, привет!
Подскажите плз, появилась ли возможность в КХ записи дат, ранее 1970 года?