Interessant genoeg dacht ik altijd dat als je naar een andere Dune-query verwijst, het behoorlijk inefficiënt zou zijn omdat de Trino-optimizer de externe query en de huidige query niet samen plant. Maar het blijkt van niet. Ik heb Query A: een tabel voor het aanbod/opname van Morpho-markten. Dit is het volledige evenementenlog, dus het zou behoorlijk zwaar moeten zijn. Dan is er Query B, die naar Query A verwijst en filtert op één specifieke market_id. Het blijkt dat Trino slim genoeg is om predicate pushdown (een chique term voor zo vroeg mogelijk filteren) op Query A uit te voeren. Simpel gezegd, het heeft mijn market_id-filter overgedragen naar Query A, ook al werd het filter toegepast op Query B. Ik weet niet zeker of Trino hetzelfde zal doen voor complexere queries. Maar de implicaties hiervan zijn: Je hoeft mogelijk niet vooraf te optimaliseren of vroeg te filteren op de basistabellen. Als je filters op de laatste-mijl tabellen hebt, die tabellen die typisch worden gebruikt om dashboards te maken, kan Trino de filters stroomopwaarts doorgeven (wat een vreemde zin). Ik was hier in het begin behoorlijk bezorgd over en heb een beetje over-geoptimaliseerd. Maar het waarschuwingswoord is dat je dit alleen kunt doen als je al verwacht dat de stroomafwaartse tabellen een soort filtering zullen hebben. Want als je deze optimalisatie niet op de stroomopwaartse tabellen doet, gaat het je veel credits kosten. Natuurlijk geldt de standaardregel in optimalisatie, zoals als je een windowfunctie uitvoert voordat je filtert op bepaalde waarden, dan gaat het je kosten omdat je windowfuncties over de hele dataset uitvoert. Niet goed. Dus echt, het ontwerp van de query hangt af van de verwachte gebruiksgevallen van de stroomafwaartse tabel. Ik weet niet zeker of ik duidelijk ben of dat dit juist is. Misschien kan iemand dit ook controleren. Het is echter best cool.