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í. Tengo la Consulta A: una tabla de mercados de Morpho de oferta y retirada. Este es el registro completo de eventos, así que debería ser bastante pesado. Luego la Consulta B, que hace referencia a la Consulta A, filtra por un market_id específico. Resulta que Trino sigue siendo lo suficientemente inteligente como para hacer predicate pushdown (término sofisticado para filtrar lo antes posible) en la Consulta A. En pocas palabras, transfirió mi filtro market_id a la Consulta A aunque el filtro se aplicaba 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 ni hacer filtros tempranos en las tablas base. Si tus filtros están en las tablas de última milla, que normalmente se usan para crear paneles, Trino puede empujar los filtros hacia arriba (qué frase tan extraña). Al principio me preocupaba bastante y estaba un poco sobreoptimizado. Pero la advertencia es que solo puedes hacer esto si ya esperas que las tablas posteriores tengan algún tipo de filtrado. Porque si no haces esta optimización en las mesas upstream, te va a costar muchos créditos. Por supuesto, la regla estándar se aplica en optimización, como que si haces una función de ventana antes de filtrar valores concretos, te va a afectar porque estarás funcionando por ventana en todo el conjunto de datos. Mal. Así que, realmente, el diseño de la consulta depende del caso de uso anticipado de la tabla posterior. No sé si lo digo o si esto es correcto. Quizá alguien también pueda echar un vistazo a esto. Aunque es bastante chulo.