È interessante, ho sempre pensato che se fai riferimento a un'altra query di Dune, sarebbe piuttosto inefficiente perché l'ottimizzatore Trino non pianifica la query esterna e la query corrente insieme. Ma si scopre che lo fa. Ho la Query A: una tabella di fornitura/prelievo dei mercati Morpho. Questo è il registro completo degli eventi, quindi dovrebbe essere piuttosto pesante. Poi c'è la Query B, che fa riferimento alla Query A, filtrando su un specifico market_id. Si scopre che Trino è ancora abbastanza intelligente da fare il predicate pushdown (un termine elegante per filtrare il prima possibile) sulla Query A. In parole povere, ha trasferito il mio filtro market_id alla Query A anche se il filtro è stato applicato sulla Query B. Non sono sicuro se, per query più complesse, Trino farà la stessa cosa. Ma le implicazioni di questo sono: Potresti non dover pre-ottimizzare o fare filtraggio anticipato sulle tabelle di base. Se i tuoi filtri sono sulle tabelle dell'ultimo miglio, che sono tabelle tipicamente utilizzate per creare dashboard, Trino è in grado di spingere i filtri a monte (che frase strana). Ero piuttosto preoccupato per questo all'inizio e ho un po' esagerato con l'ottimizzazione. Ma la parola di avvertimento è che puoi fare questo solo se ti aspetti già che le tabelle a valle avranno qualche tipo di filtraggio. Perché se non fai questa ottimizzazione sulle tabelle a monte, ti costerà molti crediti. Certo, la regola standard si applica all'ottimizzazione, come se fai una funzione finestra prima di filtrare su valori particolari, allora ti costerà caro perché stai facendo la funzione finestra su tutto il dataset. Non va bene. Quindi, in realtà, il design della query dipende dal caso d'uso previsto della tabella a valle. Non sono sicuro se sto facendo senso o se questo è giusto. Forse qualcuno può anche controllare questo. È davvero interessante però.