Interesant este că mereu am crezut că dacă faci referire la o altă interogare Dune, ar fi destul de ineficientă pentru că optimizatorul Trino nu planifică interogarea externă și interogarea curentă împreună. Dar se pare că da. Am interogarea A: un tabel de ofertă/retragere a piețelor Morpho. Acesta este jurnalul complet al evenimentelor, deci ar trebui să fie destul de greu. Apoi, Interogarea B, care face referire la Interogarea A, filtrează pe un anumit market_id. Se pare că Trino este încă suficient de inteligent să facă predicate pushdown (termen sofisticat pentru filtrare cât mai devreme) pe Interogarea A. Pe scurt, mi-a transferat filtrul market_id către Interogarea A, deși filtrul era aplicat pe Interogarea B. Nu sunt sigur dacă, pentru interogări mai complexe, Trino va face același lucru. Dar implicațiile acestui lucru sunt: S-ar putea să nu fie nevoie să pre-optimizezi sau să faci filtrare timpurie pe tabelele de bază. Dacă filtrele tale sunt pe tabelele de ultimă milă, care sunt tabele folosite de obicei pentru a crea dashboard-uri, Trino poate apăsa filtrele în amonte (ce propoziție ciudată). La început am fost destul de îngrijorat de asta și am cam optimizat prea mult. Dar avertismentul este că poți face asta doar dacă te aștepți deja ca tabelele din aval să aibă un fel de filtrare. Pentru că dacă nu faci această optimizare la tabelele din amonte, te va costa multe credite. Desigur, regula standard se aplică în optimizare, cum ar fi dacă faci o funcție de fereastră înainte de a filtra anumite valori, atunci te va afecta pentru că vei funcționa fereastra pe întregul set de date. Nu e bine. Deci, de fapt, designul interogării depinde de cazul de utilizare anticipat al tabelului downstream. Nu sunt sigur dacă am sens sau dacă este corect. Poate cineva poate verifica și asta. Totuși, e destul de tare.