Let physical-plan producers reuse a CASE's first-WHEN operand as its ELSE value

Đang mở
  • Có gì không ổn?
#27,280 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

  • #27281 của @Weijun-H — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
backend-api-design, databases

Hướng nghiên cứu

Start with CaseExpr and the physical expression evaluation path; the issue does not name specific files or tests, so first locate CaseExpr and its existing tests. Check how the first WHEN operand is evaluated and how an opt-in can preserve caller-specified evaluation order. Done means ELSE reuses that operand’s evaluated array for ELSE rows while retaining the original evaluation order; add coverage for reuse and ordering.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Is your feature request related to a problem or challenge?

CASE WHEN f(x) = 'a' THEN 'b' ELSE f(x) END evaluates f(x) for every row in the first WHEN, then again for the ELSE rows. For an expensive f the second call can dominate.

For plans that go through the logical optimizer, CommonSubexprEliminate can remove the duplicate by moving f(x) into a lower projection: with an immutable UDF f, EXPLAIN SELECT CASE WHEN f(value) = 1 THEN 100 ELSE f(value) END FROM t shows Projection: f(t.value) AS __common_expr_1 below the CASE (not extracted when f is volatile). An engine that builds physical plans directly never runs that rule. It also may not be able to use a lower projection: that evaluates f(x) before the columns preceding the CASE, so when those columns and f fail on different rows, a different error surfaces first. Spark-compatible engines need to keep the original order.

Describe the solution you'd like

An opt-in on CaseExpr: the caller states that ELSE is the same call as the operand evaluated first inside the first WHEN, and CaseExpr evaluates it once, at that position, and reuses the array for the ELSE rows. The caller supplies the evaluation-order rules, since which child a PhysicalExpr evaluates first is not part of the trait contract.

Describe alternatives you've considered
  • A lower ProjectionExec in the producer: changes which error surfaces first, as above.
  • Automatic detection inside CaseExpr: needs DataFusion to know evaluation order for every expression on the path. A built-in policy for BinaryExpr/NotExpr/CastExpr could be a follow-up.
Ngôn ngữ chính
Rust
Star
9.6k
Fork
2.6k
Merge trung bình
3 ngày 4 giờ
Pull request đã merge (30 ngày)
345

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/datafusion

Tất cả issue của apache/datafusion

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.