Цікаво, що я завжди думав, що якщо посилатися на інший запит до Dune, це буде досить неефективно, бо оптимізатор Trino не планує зовнішній і поточний запит разом. Але виявляється, що це так. У мене є Запит А: таблиця ринків Morpho/постачання/вилучення. Ось повний журнал подій, тож він має бути досить насиченим. Потім запит B, який посилається на запит A, фільтрує по одному конкретному market_id. Виявляється, Trino досі достатньо розумний, щоб робити предикатний pushdown (складний термін для фільтрації) на запиті A. Простіше кажучи, він переніс мій фільтр market_id на запит A, хоча фільтр застосовувався до запиту B. Я не впевнений, чи для більш складних запитів Trino робитиме те саме. Але наслідки цього такі: Можливо, вам не потрібно попередньо оптимізувати або робити ранню фільтрацію базових таблиць. Якщо ваші фільтри розміщені на таблицях останньої милі, які зазвичай використовуються для створення дашбордів, Trino може опускати фільтри вгору за течією (яке дивне речення). Спочатку я був досить стурбований і трохи надто оптимізував. Але попереджаю, що це можна зробити лише якщо ви вже очікуєте, що нижні таблиці матимуть якусь фільтрацію. Бо якщо не робити цю оптимізацію за верхніми столами, це коштуватиме вам багато кредитів. Звісно, стандартне правило застосовується в оптимізації, наприклад, якщо ви виконуєте віконну функцію перед фільтрацією за певними значеннями, це вас підведе, бо ви будете працювати віконно по всьому набору даних. Недобре. Отже, насправді дизайн запиту залежить від очікуваного випадку використання таблиці нижчого потоку. Не впевнений, чи я маю сенс, чи це правильно. Можливо, хтось теж зможе це ознайомитись. Але це досить круто.