等等等等，所以通過試圖歸因於供應/提取事件，vault v1 出現在 morpho 市場事件中。 但我需要追蹤之間的關係 v1 -> adapter (SCD2) -> v2 -> curator (SCD2) 😵‍💫

有趣的是，我一直認為如果你引用另一個 Dune 查詢，這會非常低效，因為 Trino 優化器不會將外部查詢和當前查詢一起計劃。 但事實證明它是可以的。 我有查詢 A：一個供應/提取 Morpho 市場的表格。這是完整的事件日誌，所以應該相當龐大。 然後是查詢 B，引用查詢 A，並在一個特定的 market_id 上進行過濾。 結果發現 Trino 仍然足夠聰明，能夠對查詢 A 進行謂詞下推（這是一個花哨的術語，意指儘早過濾）。簡單來說，它將我的 market_id 過濾器轉移到查詢 A，即使過濾是在查詢 B 上應用的。 我不確定對於更複雜的查詢，Trino 是否會做同樣的事情。但這樣的影響是： 你可能不需要對基礎表進行預優化或提前過濾。如果你的過濾器位於最後一公里的表格上，這些表格通常用於製作儀表板，Trino 能夠將過濾器向上推送（這句話真奇怪）。 我一開始對此相當擔心，並且有點過度優化。但警告是，你只能在預期下游表格會有某種過濾的情況下這樣做。因為如果你不在上游表格進行這種優化，將會花費你很多信用。 當然，優化中的標準規則適用，例如如果你在過濾特定值之前執行窗口函數，那麼這會讓你很麻煩，因為你將在整個數據集上進行窗口函數操作。這可不好。 所以，查詢的設計實際上取決於下游表格的預期使用情況。 不確定我是否說得通或這是否正確。也許有人可以檢查一下。這真的很酷。

為什麼Nescafe Gold最近這麼貴？像是每200克的瓶子快要20美元了。