fix(query): push down PromQL cast filters

[discord9]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

• fix: use cast preimages for cast predicate rewrites datafusion#11
• refactor: Use cast preimages for cast predicate rewrites apache/datafusion#22906
• GreptimeDB issue context: TIMESTAMP predicate incorrectly matches rows with higher fractional seconds #8214

What's changed and what's your intention?

This PR updates GreptimeDB's patched DataFusion revision to the fork commit that contains the cast predicate preimage fix, and wires the distributed planner so cast-based timestamp filters/projections can reach the remote datanode plan.

The original PromQL issue was a composite planner bug:

• PromQL casts non-millisecond time indexes to Timestamp(ms) for PromQL execution semantics.
• The time filter is initially built on that millisecond alias.
• Before this PR, distributed commutativity classified Expr::Cast / Expr::TryCast as Unimplemented, so cast projections could stop at the frontend side above MergeScan.
• MergeScanLogicalPlan intentionally hides its remote_input, so any missing filter/projection rewrite after wrapping cannot be recovered by later optimizer passes.

This PR fixes the path by:

1. Updating the DataFusion patch revision to fe8422ed266dc8a527c06699057c20875a465173.
2. Treating Cast / TryCast as commutative when their inner expression is commutative.
3. Running DataFusion SimplifyExpressions after the focused pre-MergeScan PushDownFilter pass, so cast-preimage can rewrite pushed scan filters such as CAST(ts_ns AS Timestamp(ms)) <= literal into native timestamp bounds.
4. Adding targeted distributed planner unit tests for cast projection pushdown and post-pushdown cast filter simplification. The latter invokes DistPlannerAnalyzer directly, bypassing the globally registered ConstNormalizationRule, so the native timestamp rewrite is covered by the pre-MergeScan SimplifyExpressions path.
5. Adding a standalone SQL sqlness case filter/cast_preimage that is not PromQL-specific and covers timestamp downcast comparison/equality/literal-left/BETWEEN, timestamp widening exact/non-exact behavior, integer widening comparison/swapped comparison/BETWEEN/NOT BETWEEN/IN, plain/casted constants, and TRY_CAST pushdown.
6. Extending the PromQL timestamp precision sqlness coverage for both instant selectors and range selectors over timestamp(6) and timestamp(9) time indexes.
7. Adding a Rust unit test that compares ConstNormalizationRule and DataFusion SimplifyExpressions case-by-case for overlapping and non-overlapping cast-normalization behavior.
8. Updating existing TQL / explain sqlness expected outputs where the improved pre-MergeScan pushdown changes plan shape.

ConstNormalizationRule vs DataFusion cast-preimage overlap

GreptimeDB still keeps its existing ConstNormalizationRule. The new DataFusion revision overlaps with part of it, but it is not a full replacement. The concrete behavior is:

Predicate shape	Greptime ConstNormalizationRule	DataFusion SimplifyExpressions / cast-preimage	Impact
CAST(v AS BIGINT) >= 42	v >= Int16(42)	v >= Int16(42)	True overlap: integer widening binary comparison behaves the same.
42 <= CAST(v AS BIGINT)	v >= Int16(42)	v >= Int16(42)	True overlap: literal-left / swapped comparison behaves the same.
TRY_CAST(v AS BIGINT) >= 42	v >= Int16(42)	v >= Int16(42)	True overlap: TRY_CAST widening can become a scan-local typed literal.
CAST(v AS BIGINT) IN (1, 2)	v IN ([Int16(1), Int16(2)])	v = Int16(1) OR v = Int16(2)	Semantic overlap, different plan shape: both become native typed predicates.
CAST(v AS BIGINT) BETWEEN 3 AND 5	v BETWEEN Int16(3) AND Int16(5)	v >= Int16(3) AND v <= Int16(5)	Indirect overlap: DataFusion reaches it after lowering BETWEEN to binary comparisons.
CAST(v AS BIGINT) NOT BETWEEN 3 AND 5	v NOT BETWEEN Int16(3) AND Int16(5)	v < Int16(3) OR v > Int16(5)	Indirect overlap with equivalent semantics but different expression shape.
v >= 42_i64	v >= Int16(42)	v >= Int64(42)	Greptime-only normalization: no cast predicate exists for DataFusion cast-preimage to handle.
v >= CAST(42_i8 AS BIGINT)	v >= Int16(42)	v >= Int64(42)	Greptime-only normalization: DataFusion folds the constant cast but does not retarget the literal to the column type.
CAST(ts_ns AS TIMESTAMP(3)) = ts_ms(5000)	keeps the cast equality	ts_ns >= 5000000000ns AND ts_ns < 5001000000ns	DataFusion is stronger: timestamp downcast equality must become a half-open native range.
CAST(ts_ms AS TIMESTAMP(9)) = ts_ns(5000000000)	keeps the cast equality	ts_ms = TimestampMillisecond(5000)	DataFusion is stronger for exact timestamp widening.

The design implication is that the focused pre-MergeScan pass can rely on DataFusion for cast-preimage rewrites after PushDownFilter, but this PR should not remove ConstNormalizationRule: it still covers Greptime-specific plain literal, casted constant, and string-pattern normalization behavior.

Compatibility:

• No API change.
• No schema or data format change.
• The planner change is limited to expression-level simplification in the focused pre-MergeScan pass; it does not add broad plan-shaping rules such as projection optimization or limit pushdown.

Validation run locally:

cargo fmt --all
cargo clippy --all-targets --all-features -- -D warnings
cargo test -p query test_table_scan_projection
cargo test -p query test_table_scan_cast_projection_pushdown
cargo test -p query test_cast_filter_simplified_after_pushdown
cargo test -p query pre_merge_scan_optimizer_eliminates_projected_false_filter
cargo test -p query test_const_normalization_vs_datafusion_cast_preimage_overlap
cargo sqlness bare -t '.*precisions.*'
cargo sqlness bare -t '.*cast_preimage.*'
cargo sqlness bare -t '.*(cast_preimage|precisions).*'
cargo sqlness bare -t '.*(general_table|explain|subqueries|cast_preimage|precisions).*'
cargo sqlness bare --enable-flat-format -t '.*(general_table|explain|subqueries|cast_preimage|precisions).*'

PR Checklist

Please convert it to a draft if some of the following conditions are not met.

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.
• API changes are backward compatible.
• Schema or data changes are backward compatible.

[gemini-code-assist]

Code Review

This pull request updates the DataFusion dependency revision and enhances the distributed query planner to support pushing down cast and try-cast expressions. Specifically, it updates the commutativity analysis to evaluate Cast and TryCast expressions based on their inner expressions, and integrates the SimplifyExpressions optimizer rule into the pre-merge scan optimizer. Additionally, new unit and integration tests (using a nanosecond-precision table host_nano) have been added to verify that PromQL time predicates on non-millisecond time indexes are correctly simplified and pushed down as native timestamp range filters. No review comments were provided, so there is no feedback to address.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Code Review

This pull request updates the DataFusion dependency to a newer revision and enhances the query planner to support pushing down and simplifying cast expressions. Specifically, it adds the SimplifyExpressions optimizer rule to the pre-merge scan optimizer and updates the commutativity categorizer to recursively check Cast and TryCast expressions. Additionally, new unit tests and integration tests with nanosecond-precision timestamps have been added to verify that PromQL time predicates on non-millisecond time indexes are correctly simplified and pushed down as native timestamp range filters. I have no feedback to provide as there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[fengjiachun]

LGTM