Привет У меня тормозит кликхаус, может кто-то подскажет :-% создаю таблицу такого

вида

CREATE TABLE newsfeed (
uuid UUID,
app_id Int32,
geo_id Int32,
field String,
value String,
md5_value String,
event_date Date,
event_datetime DateTime,
is_init UInt8,
prev_uuid UUID

) engine=MergeTree(event_date, (app_id, geo_id, field), 8192);

и потом по ней читаю вот так

SELECT md5_value
FROM newsfeed
WHERE app_id = ? AND
geo_id = ? AND
field =?
ORDER BY event_datetime desc limit 1;

данных в таблице сейчас всего 80000 штук

если запускать 1 селект, то его время 0.007 sec

если запустить 20 воркеров, которые будут делать такого плана запросы, то время выполнения каждого вырастает до 0.5 sec и очень сильно возрастает CPU usage

вот кусок из лога

2019.01.10 18:52:54.441555 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Debug> executeQuery: (from [::1]:27218) SELECT md5_value FROM newsfeed WHERE app_id = 207052
2019.01.10 18:52:54.442739 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Debug> apptica_stat.newsfeed (SelectExecutor): Key condition: (column 0 in [207052, 207052])
2019.01.10 18:52:54.442857 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Debug> apptica_stat.newsfeed (SelectExecutor): MinMax index condition: unknown
2019.01.10 18:52:54.442927 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Debug> apptica_stat.newsfeed (SelectExecutor): Selected 2 parts by date, 2 parts by key, 2 marks to read from 2 ranges
2019.01.10 18:52:54.443084 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Trace> apptica_stat.newsfeed (SelectExecutor): Reading approx. 16384 rows with 2 streams
2019.01.10 18:52:54.443174 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
2019.01.10 18:52:54.443371 [ 9733 ] {596ee62a-3ba7-460f-9c52-34e2086f1dec} <Debug> executeQuery: Query pipeline:
Union
Expression × 2
Expression
Filter
MergeTreeThread

это не аналитический запрос. КХ не предназначен для навигационных запросов по индексу, тем более там нет никаких оптимизаций для ORDER BY event_datetime desc limit 1 этот запрос будет работать все дольше и дольше с каждым днем, нужен фильтр хотя бы event_date >= и event_date в индексе.