Curiosamente, siempre pensé que si referenciabas otra consulta de Dune, sería bastante ineficiente porque el optimizador de Trino no planifica la consulta externa y la consulta actual juntas. Pero resulta que sí lo hace. Tengo la Consulta A: una tabla de suministro/retiro de los mercados de Morpho. Este es el registro completo de eventos, por lo que debería ser bastante pesado. Luego la Consulta B, que referencia la Consulta A, filtra por un market_id específico. Resulta que Trino es lo suficientemente inteligente como para hacer un "predicate pushdown" (término elegante para filtrar lo antes posible) en la Consulta A. En pocas palabras, transfirió mi filtro de market_id a la Consulta A, aunque el filtro se aplicó en la Consulta B. No estoy seguro de si, para consultas más complejas, Trino hará lo mismo. Pero las implicaciones de esto son: Puede que no necesites preoptimizar o hacer filtrado temprano en las tablas base. Si tus filtros están en las tablas de última milla, que son tablas que se utilizan típicamente para hacer paneles, Trino puede empujar los filtros hacia arriba (qué frase tan extraña). Al principio estaba bastante preocupado por esto y optimicé demasiado. Pero la advertencia es que solo puedes hacer esto si ya esperas que las tablas de abajo tengan algún tipo de filtrado. Porque si no haces esta optimización en las tablas de arriba, te costará muchos créditos. Por supuesto, la regla estándar se aplica en la optimización, como si haces una función de ventana antes de filtrar por valores particulares, entonces te va a perjudicar porque estarás haciendo funciones de ventana en todo el conjunto de datos. No es bueno. Así que realmente, el diseño de la consulta depende del caso de uso anticipado de la tabla de abajo. No estoy seguro de si tiene sentido o si esto es correcto. Tal vez alguien también pueda revisar esto. Sin embargo, es bastante genial.