(for query) exceeded
Версия 19.3.5
Запрос вида:
SELECT /* fields */
FROM (
SELECT some_id1, some_id2, max(publish_seq_id) as psi
FROM tbl
WHERE /* conditions */
GROUP BY some_id1, some_id2
) i
INNER JOIN tbl t
ON t.some_id1 = i.some_id1
AND t.some_id2 = i.some_id2
AND t.publish_seq_id = i.psi
WHERE /* same conditions as above */
ORDER BY ...
LIMIT x OFFSET yINNER JOIN такого вида задумывался для дедупликации записей в ReplicatedReplacingMergeTree в момент, когда схлопывание ещё не произошло. Сам запрос делается из Distributed таблицы, использующий эти реплицированные.
Ошибка возникает даже когда считанные единицы или вообще ноль записей удовлетворяет условиям.
Подскажите, пожалуйста, ответы на вопросы:
1. Это у меня подход с JOIN не соответствует архитектуре БД?
2. Можно ли ошибку исправить апгрейдом версии сервера?
3. Или построением каких-то индексов?
4. Или может для данной цели (выборка с дедупликацией) есть какой-то более штатный/общеиспользуемый подход?
может быть поможет INNER JOIN ( SELECT FROM tbl WHERE… )
1. выбирать левой надо более крупную таблицу, 2. пушдаун есть, но не всегда работает 3. для фильтрации дублей в ReplacingMergeTree есть SEMI LEFT JOIN (в старом синтаксисе ANY INNER - это если с выставленным any_join_distinct_right_table_keys) - он не размножает дубли как обычный INNER JOIN, поэтому работает быстрее P.S. но в конкретном случае (фильтрации крупной таблицы самой по себе с пэйджинком) этого будет не достаточно - правая таблица все равно не влезет в память, засуньте LIMIT в подзапрос для правой таблицы SEMI LEFT JOIN
>> задумывался для дедупликации записей по своему опыту скажу, что делать джойны для исправления этой особенности КХ - плохая идея Варианты: - делать optimize table final перед единичными чтениями, если возможно - делать limit 1 by "ключ" с правильной сортировкой - не делать ничего, осознавая что могут быть временные неточности из-за этого ЗЫ В последней версии должны были добавить возможность скидывать на диск тяжелые джойны (по аналогии с тем, что есть для group by), но не знаю добавили ли. Но это тоже не вариант для этой цели
SELECT some_id1, some_id2, argMax(tuple(*),publish_seq_id) FROM tbl WHERE /* conditions */ GROUP BY some_id1, some_id2
Обсуждают сегодня