Конечно увидите. Optimize вызывает незапланированный обычный мерж

Скорее всего успешно закончился optimize. Он не может отманится

Непонятно. Скорее всего нет, т.к. запрос с FINAL и без FINAL дают разные результаты (как и до optimize)

Более того - теперь у меня в логах такое:

(ReplicatedMergeTreeQueue): Not executing log entry MERGE_PAR
TS for part 202005_0_2566_9 because source parts size (370.71 GiB) is greater than the current maximum (33.71 GiB).

Ну так final принудительно оптимизирует все. А оптимайз хз когда выполнится

Ее только в профиле и можно установить. Где она была до этого? Для кафки лучше вообще не ставить, но да в профиле дефаулт. В остальных профилях придется отменить, потому что они унаследуют.

Была в основном конфиге

Часовой пояс применяется клиентами при рендеринге в строки

Емм, я наверное неправильно выразился - я имел в виду SELECT FROM FINAL. Т.е. если OPTIMIZE и выполнился, то дубликаты все еще на месте

Значит не работала, старые кх не проверяли просто, что не в тот конфиг вписано

понятно, спасибо

да конечно, сделал: https://github.com/Vertamedia/clickhouse-grafana/issues/230

Спасибо

КХ, типа, не тормозит, но заставляет тормозить привязанный к нему Мускуль :)

SELECT id FROM my.test LIMIT 1;

1 rows in set. Elapsed: 0.153 sec.

SELECT id FROM my.test WHERE id < 2000;

4 rows in set. Elapsed: 0.117 sec. 

SELECT id FROM my.test WHERE id > 2000 LIMIT 1;

1 rows in set. Elapsed: 1.242 sec. Processed 65.54 thousand rows, 524.29 KB (52.75 thousand rows/s., 421.96 KB/s.) 

Видно, что оптимизация есть: после чтения 64К записей коннект прервался (а их там больше). Но LIMIT не пробрасывается в MySQL, в результате чего по сети гоняется рулон лишних данных.

SELECT id FROM my.test LIMIT 1;

1 rows in set. Elapsed: 0.153 sec.

SELECT id FROM my.test WHERE id < 2000;

4 rows in set. Elapsed: 0.117 sec. 

SELECT id FROM my.test WHERE id > 2000 LIMIT 1;

1 rows in set. Elapsed: 1.242 sec. Processed 65.54 thousand rows, 524.29 KB (52.75 thousand rows/s., 421.96 KB/s.) 

да limit не пробрасывается. Это сделано специально, есть issue на гитхабе где описано почему

SELECT id FROM my.test LIMIT 1;

1 rows in set. Elapsed: 0.153 sec.

SELECT id FROM my.test WHERE id < 2000;

4 rows in set. Elapsed: 0.117 sec. 

SELECT id FROM my.test WHERE id > 2000 LIMIT 1;

1 rows in set. Elapsed: 1.242 sec. Processed 65.54 thousand rows, 524.29 KB (52.75 thousand rows/s., 421.96 KB/s.) 

А с ORDER BY совсем печально: получает на себя все гуголиарды записей, потом сортирует и выбирает лимит.

Я догадываюсь, почему (связанные запросы из нескольких баз и всё такое). Но в простейших случаях, коих большинство, выглядит весьма плачевно.

нет, не поэтому. КХ не знает синтаксис mysql / pg/ informix/ mssql и не знает умеют они limit или нет

Всем привет! Подскажите пожалуйста, как в новом синтаксисе создания ReplicatedMergeTree таблиц указать поле date column для метадаты зукипера?
Если раньше мы создавали таблицу так

CREATE TABLE test.foo(`date` Date, `created` DateTime, `value` Int32) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/foo', '{replica}', date, value, 8192);

И получали такую метадату в зк

[zk: localhost:2181(CONNECTED) 5] get /clickhouse/tables/1/foo/metadata
metadata format version: 1
date column: date
sampling expression: 
index granularity: 8192
mode: 0
sign column: 
primary key: value
granularity bytes: 10485760

То теперь создаем так

CREATE TABLE test.bar 
(
  `date` Date, 
  `created` DateTime, 
  `value` Int32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/bar', '{replica}') 
PARTITION BY date
ORDER BY value
SETTINGS index_granularity = 8192

И получаем такую

[zk: localhost:2181(CONNECTED) 6] get /clickhouse/tables/1/bar/metadata
metadata format version: 1
date column: 
sampling expression: 
index granularity: 8192
mode: 0
sign column: 
primary key: value
data format version: 1
partition key: date
granularity bytes: 10485760

Видим что поле date column пустое. Изначальный кейс - хотим явно задавать index_granularity_bytes, но в старом синтаксисе не можем.

Ну, синтаксис MySQL он в целом знает. Это же не JDBC какой, а "нативный" протокол, встроенный в Кликхаус.