производительность?
есть таблица
CREATE MATERIALIZED VIEW item_status_mv
(
`item` String,
.....
.....
)
ENGINE = AggregatingMergeTree
PRIMARY KEY item
ORDER BY item
Запрос
SELECT
ds.item
FROM item_status_mv AS ds
FINAL
WHERE
ds.item > ''
ORDER BY item
LIMIT 1000;
Выполняется за большое время, "1000 rows in set. Elapsed: 11.728 sec. Processed 401.69 million rows"
если убрать FINAL или ORDER BY то все летает.
Почему клик не хочет использовать индекс? Ведь по логике все просто и легко идем по индексу , считали все записи для первого item , сделали финальную аггрегацию и отдали, повторили для второго item. Но клик зачем-то считывает всю базу
По идее, можно клик заставить работать как хочется путем запроса SELECT ds.item FROM item_status_mv AS ds FINAL WHERE ds.item > '' GROUP BY item LIMIT 1000 SETTINGS optimize_aggregation_in_order = 1 Те заменить ORDER BY на GROUP BY + optimize_aggregation_in_order , но часть запросов отрабатывает нормально, а часть запросов валится с ошибкой Progress: 26.42 million rows, 1.30 GB (6.24 million rows/s., 306.06 MB/s.) ███▍ 6% Received exception from server (version 21.1.10): Code: 49. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Pipeline stuck. Current state: digraph { rankdir="LR"; { node [shape = box] n140638677604384[label="MergeTree(1565 jobs) (PortFull)"]; n140638673862688[label="MergeTree(5 jobs) (PortFull)"];
а optimize_read_in_order пробовали?
SELECT ds.item FROM item_status_mv AS ds FINAL WHERE ds.item > '' GROUP BY item LIMIT 1000 SETTINGS optimize_aggregation_in_order = 1, optimize_read_in_order= 1, max_threads = 2 тоже валится, но причиной оказлся max_threads = 2 , я его не указал в исходном сообщении Поэтому теперь уже два вопроса :) 1) Почему ORDER BY не использует индекс 2) max_threads=2 и падение с ошибкой - это нормально или бага?
я имел в виду без group by, а с order by попробовать указать optimize_read_in_order= 1
Обсуждают сегодня