Thú vị là, tôi luôn nghĩ rằng nếu bạn tham chiếu một truy vấn Dune khác, điều đó sẽ khá không hiệu quả vì trình tối ưu hóa Trino không lập kế hoạch cho truy vấn bên ngoài và truy vấn hiện tại cùng nhau. Nhưng hóa ra là nó có thể. Tôi có Truy vấn A: một bảng thị trường Morpho cung cấp/rút tiền. Đây là nhật ký sự kiện đầy đủ, vì vậy nó sẽ khá nặng. Sau đó là Truy vấn B, tham chiếu đến Truy vấn A, lọc theo một market_id cụ thể. Hóa ra Trino vẫn đủ thông minh để thực hiện predicate pushdown (thuật ngữ fancy cho việc lọc càng sớm càng tốt) trên Truy vấn A. Nói đơn giản, nó đã chuyển bộ lọc market_id của tôi sang Truy vấn A mặc dù bộ lọc được áp dụng trên Truy vấn B. Tôi không chắc rằng, đối với các truy vấn phức tạp hơn, Trino sẽ làm điều tương tự. Nhưng những hệ quả của điều này là: Bạn có thể không cần phải tối ưu hóa trước hoặc thực hiện lọc sớm trên các bảng cơ sở. Nếu bộ lọc của bạn nằm trên các bảng cuối cùng, mà thường được sử dụng để tạo bảng điều khiển, Trino có khả năng đẩy bộ lọc lên phía trên (thật là một câu lạ lùng). Tôi đã khá lo lắng về điều này lúc đầu và đã tối ưu hóa quá mức. Nhưng lời cảnh báo là bạn chỉ có thể làm điều này nếu bạn đã mong đợi rằng các bảng phía dưới sẽ có một số loại lọc. Bởi vì nếu bạn không thực hiện tối ưu hóa này trên các bảng phía trên, nó sẽ khiến bạn tốn rất nhiều tín dụng. Tất nhiên, quy tắc tiêu chuẩn áp dụng trong tối ưu hóa như nếu bạn thực hiện một hàm cửa sổ trước khi lọc theo các giá trị cụ thể thì nó sẽ khiến bạn gặp rắc rối vì bạn sẽ thực hiện hàm cửa sổ trên toàn bộ tập dữ liệu. Không tốt. Vì vậy, thực sự, thiết kế của truy vấn phụ thuộc vào trường hợp sử dụng dự kiến của bảng phía dưới. Không chắc tôi có đang nói đúng hay không. Có thể ai đó cũng có thể kiểm tra điều này. Nhưng thật sự thú vị.