Menariknya, saya selalu berpikir jika Anda mereferensikan kueri Dune lain, itu akan sangat tidak efisien karena pengoptimal Trino tidak merencanakan kueri eksternal dan kueri saat ini bersama-sama. Tapi ternyata memang demikian. Saya memiliki Kueri A: tabel pasar Morpho/penarikan. Ini adalah log peristiwa lengkap, jadi seharusnya cukup berat. Kemudian Kueri B, yang mereferensikan Kueri A, memfilter pada satu market_id tertentu. Ternyata Trino masih cukup pintar untuk melakukan predikat pushdown (istilah mewah untuk memfilter sedini mungkin) pada Kueri A. Sederhananya, itu mentransfer filter market_id saya ke Kueri A meskipun filter diterapkan pada Kueri B. Saya tidak yakin apakah, untuk pertanyaan yang lebih kompleks, Trino akan melakukan hal yang sama. Tetapi implikasinya adalah: Anda mungkin tidak perlu mengoptimalkan terlebih dahulu atau melakukan pemfilteran awal pada tabel dasar. Jika filter Anda berada di tabel mil terakhir, yang merupakan tabel yang biasanya digunakan untuk membuat dasbor, Trino dapat mendorong filter ke hulu (kalimat yang aneh). Saya cukup khawatir tentang ini pada awalnya dan agak terlalu dioptimalkan. Tetapi kata peringatannya adalah bahwa Anda hanya dapat melakukan ini jika Anda sudah mengharapkan bahwa tabel hilir akan memiliki semacam pemfilteran. Karena jika Anda tidak melakukan pengoptimalan ini di meja hulu, itu akan menghabiskan banyak kredit. Tentu saja aturan standar berlaku dalam pengoptimalan, seperti jika Anda melakukan fungsi jendela sebelum memfilter nilai tertentu, maka itu akan memasak Anda karena Anda akan berfungsi jendela di seluruh kumpulan data. Tidak baik. Jadi sungguh, desain kueri tergantung pada kasus penggunaan tabel hilir yang diantisipasi. Tidak yakin apakah saya masuk akal atau apakah ini benar. Mungkin seseorang juga bisa memeriksanya. Ini cukup keren.