興味深いことに、別のDuneクエリを参照すると、Trinoオプティマイザーは外部クエリと現在のクエリを同時に計画していないため、かなり非効率的だと思っていました。 しかし、実際にはそうなっています。 クエリAがあります:Morpho Marketsの供給/引き出しテーブルです。これはイベントの全記録なので、かなり重い内容になるはずです。 次にクエリBはクエリAを参照し、特定のmarket_idに絞り込みます。 実はTrinoはクエリAに対しても十分賢く、できるだけ早くフィルタリングを行うことができます。簡単に言えば、フィルターがQuery Bに適用されているにもかかわらず、market_idフィルターをクエリAに転送してしまいました。 より複雑なクエリに対してTrinoが同じことをするかどうかはわかりません。しかし、このことの示唆は以下の通りです: ベーステーブルで事前最適化や早期フィルタリングを行う必要はないかもしれません。フィルターがダッシュボード作成に使われるラストマイルテーブル上にある場合、Trinoはフィルターを上流に押し下げることができます(なんて奇妙な文言でしょう)。 最初はかなり心配で、少し最適化しすぎた気がしました。ただし注意点として、これは下流テーブルに何らかのフィルタリングが期待されている場合にのみ可能です。なぜなら、上流のテーブルでこの最適化をしなければ、多くのクレジットを失うことになるからです。 もちろん、最適化では標準的なルールが適用されます。例えば、特定の値でフィルタリングする前にウィンドウ関数をすると、データセット全体でウィンドウ関数を操作するため、うまくいかなくなります。よくないです。 つまり、クエリの設計は下流テーブルの想定されるユースケースに依存します。 自分の言っていることが正しいのか、あるいは正しいのか分かりません。誰かこの話もチェックしてくれるかもしれません。でもかなりクールです。