Интересно, я всегда думал, что если вы ссылаетесь на другой запрос Dune, это будет довольно неэффективно, потому что оптимизатор Trino не планирует внешний запрос и текущий запрос вместе. Но оказывается, что он это делает. У меня есть Запрос A: таблица поставок/выводов на рынках Morpho. Это полный журнал событий, так что он должен быть довольно тяжелым. Затем Запрос B, который ссылается на Запрос A, фильтрует по одному конкретному market_id. Оказывается, Trino все еще достаточно умен, чтобы выполнять предикатное продвижение (модный термин для фильтрации как можно раньше) на Запросе A. Проще говоря, он перенес мой фильтр market_id на Запрос A, даже несмотря на то, что фильтр применялся к Запросу B. Я не уверен, будет ли Trino делать то же самое для более сложных запросов. Но последствия этого таковы: Вам может не понадобиться предварительная оптимизация или ранняя фильтрация на базовых таблицах. Если ваши фильтры находятся на таблицах последней мили, которые обычно используются для создания панелей управления, Trino может продвигать фильтры вверх по потоку (какое странное предложение). Сначала я был довольно обеспокоен этим и немного переоптимизировал. Но предостережение заключается в том, что вы можете сделать это только в том случае, если уже ожидаете, что таблицы вниз по потоку будут иметь какую-то фильтрацию. Потому что если вы не сделаете эту оптимизацию на таблицах вверх по потоку, это будет стоить вам много кредитов. Конечно, стандартное правило применимо в оптимизации, такое как если вы выполняете оконную функцию перед фильтрацией по определенным значениям, то это вас «приготовит», потому что вы будете выполнять оконную функцию по всему набору данных. Не хорошо. Так что на самом деле, дизайн запроса зависит от предполагаемого случая использования таблицы вниз по потоку. Не уверен, имеет ли это смысл или правильно ли это. Может быть, кто-то также может это проверить. Это довольно круто.