(SELECT … FROM Y) фильтры из внешнего запроса оптимизатором будут использовать для оптимизации внутреннего?
Или внутренний проедется по всей таблице?
по всей таблице, емнип. По крайней мере можете проверить трейсингом логов
есть ли варианты избежать такого поведения? в таблице хранится версионированная информация (id, version), хочется собирать агрегаты по id, при этом учитывая только строки с version, максимальным для данного id VersionedCollapsingMergeTree кажется сильно напрашивается, но не уверены, что именно он подохдит лучше всего
а вы тыкали в перфоманс запросов? проверьте сколько выполняется времени запрос и удовлетворяет ли он по таймингу
ну если при агрегации для конкретного id и набор фильтров нам будет полностью вся табличка ”дедуплицироваться”(т.е. возвращаться подтаблица с максимальными version для данного id), то перформанса точно не хватит) кажется, там по 7кк записей в день добавлется в пределе
это получается у вас запрос вида select max(version) from test_table where id in (select id from test_table), где одна и так же таблица?
почитал доку - скорее даже так WITH last_version_of_business_column AS ( SELECT argMax(business_column, version) FROM table ) SELECT id, sum(last_version_of_business_column) FROM table WHERE *FILTERS* GROUP BY something FILTERS зачастую выглядят как id = ID_VALUE, timestamp BETWEEN NOW()-30d and NOW() итд вопрос в том, чтобы при исполнении подзапроса, учитывались FILTERS, т.к. делать фуллскан будет очень дорого.
Обсуждают сегодня