Ciekawe, zawsze myślałem, że jeśli odwołasz się do innego zapytania Dune, będzie to dość nieefektywne, ponieważ optymalizator Trino nie planuje zapytania zewnętrznego i bieżącego zapytania razem. Ale okazuje się, że tak nie jest. Mam Zapytanie A: tabelę rynków Morpho dotyczących podaży/wycofania. To jest pełny dziennik zdarzeń, więc powinno być dość ciężkie. Następnie Zapytanie B, które odnosi się do Zapytania A, filtruje po jednym konkretnym market_id. Okazuje się, że Trino jest wystarczająco inteligentne, aby zastosować pushdown predykatów (fancy termin na filtrowanie tak wcześnie, jak to możliwe) w Zapytaniu A. Mówiąc prosto, przeniosło mój filtr market_id do Zapytania A, mimo że filtr był zastosowany w Zapytaniu B. Nie jestem pewien, czy w przypadku bardziej złożonych zapytań Trino będzie robić to samo. Ale implikacje tego są następujące: Możesz nie potrzebować wstępnej optymalizacji ani wczesnego filtrowania na tabelach bazowych. Jeśli twoje filtry są na tabelach ostatniej mili, które są tabelami zazwyczaj używanymi do tworzenia pulpitów, Trino jest w stanie przenieść filtry w górę (jakie dziwne zdanie). Na początku byłem tym dość zaniepokojony i trochę przesadziłem z optymalizacją. Ale ostrzeżenie jest takie, że możesz to zrobić tylko wtedy, gdy już oczekujesz, że tabele downstream będą miały jakiś rodzaj filtrowania. Ponieważ jeśli nie zastosujesz tej optymalizacji na tabelach upstream, będzie cię to kosztować dużo kredytów. Oczywiście standardowa zasada dotyczy optymalizacji, taka jak to, że jeśli wykonasz funkcję okna przed filtrowaniem po określonych wartościach, to cię to zrujnuje, ponieważ będziesz funkcjonować w oknie na całym zbiorze danych. Nie dobrze. Więc naprawdę, projekt zapytania zależy od przewidywanego przypadku użycia tabeli downstream. Nie jestem pewien, czy ma to sens, czy to jest poprawne. Może ktoś też to sprawdzi. To całkiem fajne.