`ScalarUdfImpl::strictly_order_preserving`: Allow expression to report whether they keep the same ordering of the input by rluvaton · Pull Request #23807 · apache/datafusion

rluvaton · 2026-07-22T15:04:48Z

Which issue does this PR close?

ClosesProjectExec does not keep sorting information for passthrough expression #23798

Related to:

[MAJOR] Equivalence System Overhaul #16217

Rationale for this change

To be able to keep the same sorting order allowing for more optimizations

Now comet own cast implementation can be recognized as not modifying sort order in the same cases that datafusion cast does.

What changes are included in this PR?

added strictly_order_preserving property to ExprProperties + varius other places
and replaced the hard coded logic for cast (substitute_cast_ordering) about keeping input order with more generic approach that now any expression can implement and have the same advantage of sort elimination

also marked from_unixtime as keeping ordering to show a case of this optimization

Are these changes tested?

yes

Are there any user-facing changes?

yes, breaking change, added strictly_order_preserving property to ExprProperties and to FFI_ExprProperties

this property means that given expression f and 2 values from the input column a and b the following variants are kept:

a.cmp(b) == f(a).cmp(f(b))
nulls maps to nulls

Example of satisfying expression:
cast(col_a as BIGINT) where col_a is INT it is keeping the properties

Example of not satisfying:

floor - floor can not

array_repeat(my_col, 2) which might look like at first glance as keeping the property as well but in fact it does not.

the reason is that array_repeat(null, 2) will output list of 2 nulls which breaks the 2nd property that nulls must be kept as nulls

how to migrate:

Option 1 - keeping the old behavior (safest but least performant)
set strictly_order_preserving to false

Option 2 - Using the new optimization that this opens up:
set strictly_order_preserving only if the expression keep both variants

⚠️ Also look for code that blindly copy child properties since it will copy the child strictly order preserving as well which will lead to wrong results

fnget_properties(&self,children:&[ExprProperties]) -> Result<ExprProperties>{// ⚠️ Clone here is BAD since you take the following 2 properties from your child that might not be true in your case:// - `preserves_lex_ordering`// - `strictly_order_preserving`// both of them should never be taken from the child as is since they talk about **this** expression Ok(children[0].clone())}

github-actions · 2026-07-22T15:19:35Z

Thank you for opening this pull request!

Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch).

Details

 Cloning apache/main
Building datafusion v54.1.0 (current)
Built [ 110.793s] (current)
Parsing datafusion v54.1.0 (current)
Parsed [ 0.037s] (current)
Building datafusion v54.1.0 (baseline)
Built [ 109.080s] (baseline)
Parsing datafusion v54.1.0 (baseline)
Parsed [ 0.038s] (baseline)
Checking datafusion v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.907s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 222.448s] datafusion
Building datafusion-expr v54.1.0 (current)
Built [ 26.512s] (current)
Parsing datafusion-expr v54.1.0 (current)
Parsed [ 0.081s] (current)
Building datafusion-expr v54.1.0 (baseline)
Built [ 26.338s] (baseline)
Parsing datafusion-expr v54.1.0 (baseline)
Parsed [ 0.082s] (baseline)
Checking datafusion-expr v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 1.863s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 56.283s] datafusion-expr
Building datafusion-expr-common v54.1.0 (current)
Built [ 18.621s] (current)
Parsing datafusion-expr-common v54.1.0 (current)
Parsed [ 0.020s] (current)
Building datafusion-expr-common v54.1.0 (baseline)
Built [ 18.459s] (baseline)
Parsing datafusion-expr-common v54.1.0 (baseline)
Parsed [ 0.021s] (baseline)
Checking datafusion-expr-common v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.282s] 223 checks: 222 pass, 1 fail, 0 warn, 30 skip
--- failure constructible_struct_adds_field: externally-constructible struct adds field ---
Description:
A pub struct constructible with a struct literal has a new pub field. Existing struct literals must be updated to include the new field.
ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.49.0/src/lints/constructible_struct_adds_field.ron
Failed in:
field ExprProperties.strictly_order_preserving in /home/runner/work/datafusion/datafusion/datafusion/expr-common/src/sort_properties.rs:198
Summary semver requires new major version: 1 major and 0 minor checks failed
Finished [ 38.131s] datafusion-expr-common
Building datafusion-ffi v54.1.0 (current)
Built [ 59.438s] (current)
Parsing datafusion-ffi v54.1.0 (current)
Parsed [ 0.065s] (current)
Building datafusion-ffi v54.1.0 (baseline)
Built [ 60.755s] (baseline)
Parsing datafusion-ffi v54.1.0 (baseline)
Parsed [ 0.068s] (baseline)
Checking datafusion-ffi v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.330s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 122.024s] datafusion-ffi
Building datafusion-functions v54.1.0 (current)
Built [ 30.721s] (current)
Parsing datafusion-functions v54.1.0 (current)
Parsed [ 0.092s] (current)
Building datafusion-functions v54.1.0 (baseline)
Built [ 31.054s] (baseline)
Parsing datafusion-functions v54.1.0 (baseline)
Parsed [ 0.095s] (baseline)
Checking datafusion-functions v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.619s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 63.807s] datafusion-functions
Building datafusion-physical-expr v54.1.0 (current)
Built [ 29.108s] (current)
Parsing datafusion-physical-expr v54.1.0 (current)
Parsed [ 0.053s] (current)
Building datafusion-physical-expr v54.1.0 (baseline)
Built [ 29.378s] (baseline)
Parsing datafusion-physical-expr v54.1.0 (baseline)
Parsed [ 0.054s] (baseline)
Checking datafusion-physical-expr v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.486s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 59.929s] datafusion-physical-expr
Building datafusion-sqllogictest v54.1.0 (current)
Built [ 191.897s] (current)
Parsing datafusion-sqllogictest v54.1.0 (current)
Parsed [ 0.023s] (current)
Building datafusion-sqllogictest v54.1.0 (baseline)
Built [ 185.890s] (baseline)
Parsing datafusion-sqllogictest v54.1.0 (baseline)
Parsed [ 0.024s] (baseline)
Checking datafusion-sqllogictest v54.1.0 -> v54.1.0 (no change; assume patch)
Checked [ 0.120s] 223 checks: 223 pass, 30 skip
Summary no semver update required
Finished [ 380.933s] datafusion-sqllogictest

rluvaton · 2026-07-22T15:20:10Z

Cc @andygrove, @mbutrovich, @ozankabak

getChan · 2026-07-22T16:55:43Z

- if is_order_preserving_cast_family(&child.range.data_type(), target_type) {
- Ok(child.clone().with_range(unbounded))
+ let source_type = child.range.data_type();
+ // A widening cast is additionally one-to-one, so it is strictly


I may not have full context, so please feel free to ignore this if it's a misunderstanding.
CastExpr::check_bigger_cast includes Int32 -> Float32 and Int64 -> Float64. Due to float mantissa limits, large integers lose precision and can collapse to the same float value (e.g. 16_777_216_i32 as f32 == 16_777_217_i32 as f32), so they are not strictly 1-to-1

You are right, unfortunately this moved from here (so no logic change has been made):
datafusion/datafusion/physical-expr/src/equivalence/properties/mod.rs
Line 215 in e271f65
&& CastExpr::check_bigger_cast(cast_expr.cast_type(), expr_type))

filed. #23808

rluvaton · 2026-07-22T16:58:53Z

 preserves_lex_ordering: value.preserves_lex_ordering,
+ // Not carried over the FFI boundary (it would break the ABI);
+ // stay conservative.
+ strictly_order_preserving: false,


Should I make breaking change in FFI (by adding the field) while I'm here to avoid 2 breaking changes? I'm not really familiar with this module

cc @timsaucer

I've read .ai/skills/datafusion-ffi/SKILL.md (ironic) and saw that it is ok to make breaking change, just not release them in a patch version

so I added the field here

rluvaton · 2026-07-22T17:01:12Z

- if is_order_preserving_cast_family(&child.range.data_type(), target_type) {
- Ok(child.clone().with_range(unbounded))
+ let source_type = child.range.data_type();
+ // A widening cast is additionally one-to-one, so it is strictly


You are right, unfortunately this moved from here (so no logic change has been made):
datafusion/datafusion/physical-expr/src/equivalence/properties/mod.rs
Line 215 in e271f65
&& CastExpr::check_bigger_cast(cast_expr.cast_type(), expr_type))

codecov-commenter · 2026-07-22T20:34:53Z

Codecov Report

❌ Patch coverage is 86.59794% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.66%. Comparing base (7576762) to head (ad7d27b).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...tafusion/physical-expr/src/equivalence/ordering.rs	72.00%	0 Missing and 7 partials ⚠️
...on/physical-expr/src/equivalence/properties/mod.rs	84.84%	0 Missing and 5 partials ⚠️
datafusion/physical-expr/src/scalar_function.rs	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #23807 +/- ##
==========================================
- Coverage 80.66% 80.66% -0.01% 
==========================================
Files 1094 1095 +1 Lines 371671 372376 +705 Branches 371671 372376 +705 ==========================================
+ Hits 299817 300380 +563 - Misses 53958 54067 +109 - Partials 17896 17929 +33

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

alamb

Thank you @rluvaton -- this idea here seems sound to me

Can we get some sql logic / explain test that show some of the optimizations that this allows for (that preserves_lex_ordering does not)?

I think having those examples would make sure we have a good / minimal API to build on -- without such "end visible facing" tests I fear we may implement some features that are not ever used

alamb · 2026-07-24T20:05:45Z

 Ok(false)
 }

+ /// Returns true if the function is strictly order-preserving with respect


How is this related to the output_ordering method? I am wondering if we can extend that rather tan introduce a new method
https://docs.rs/datafusion/latest/datafusion/logical_expr/trait.ScalarUDFImpl.html#method.output_ordering

output_ordering does not tell you whether you can reuse the existing ordering when you have multiple order by keys (with how ties are handled)

alamb · 2026-07-24T20:06:59Z

+ ///
+ /// This is not simply a stricter [`Self::preserves_lex_ordering`] — the
+ /// two properties also assume different input orderings, and with
+ /// multiple ordered inputs neither implies the other. Monotone but


It would have helped me to move these examples up to the top of the docs

alamb · 2026-07-24T20:07:18Z

 preserves_lex_ordering: value.preserves_lex_ordering,
+ // Not carried over the FFI boundary (it would break the ABI);
+ // stay conservative.
+ strictly_order_preserving: false,


cc @timsaucer

rluvaton · 2026-07-25T17:35:19Z

Thank you @rluvaton -- this idea here seems sound to me
Can we get some sql logic / explain test that show some of the optimizations that this allows for (that preserves_lex_ordering does not)?
I think having those examples would make sure we have a good / minimal API to build on -- without such "end visible facing" tests I fear we may implement some features that are not ever used

I did not want to add uses of this api in this PR to reduce the amount of code to review, do you still want me to do so?

rluvaton · 2026-07-25T20:07:51Z

Can we get some sql logic / explain test that show some of the optimizations that this allows for (that preserves_lex_ordering does not)?

~~Done, array_repeat is now no longer remove the ordering~~
actually array_repeat does not map null to null, changed to from_unixtime

…d-ordering # Conflicts: # datafusion/expr-common/src/sort_properties.rs # datafusion/expr/src/udf.rs

rluvaton · 2026-07-26T18:28:39Z

@alamb can you please take another look?

…xpr::check_bigger_cast (apache#23808) (apache#23809) ## Which issue does this PR close? - Closesapache#23808. ## Rationale for this change ref. apache#23807 `CastExpr::check_bigger_cast` is used to determine whether a cast is a widening (order-preserving) conversion. Currently, it classifies `Int32 -> Float32`, `UInt32 -> Float32`, `Int64 -> Float64`, and `UInt64 -> Float64` as widening casts. However, integer-to-float conversions for 32-bit and 64-bit integers lose precision when values exceed the mantissa bit limit (24 bits for `Float32`, 53 bits for `Float64`). For example: `16_777_216_i32 as f32 == 16_777_217_i32 as f32` (both yield 16777216.0f32). Because distinct integer inputs can collapse to the same float output, these casts are not strictly 1-to-1 (injective) and can break suffix sort key ordering in multi-column ordering analysis (e.g. `[CAST(a AS Float32), b]`). ## What changes are included in this PR? - Updated `CastExpr::check_bigger_cast` to exclude precision-losing integer-to-float conversions (`Int32/UInt32 -> Float32` and `Int64/UInt64 -> Float64`). - Added unit test `test_check_bigger_cast_precision_loss` to verify precision-losing casts return `false` while exact conversions (`Int16 -> Float32`, `Int32 -> Float64`, etc.) continue to return `true`. ## Are these changes tested? Yes, new unit test `test_check_bigger_cast_precision_loss` in `cast.rs`. ## Are there any user-facing changes? No breaking API changes. Internal optimizer behavior fix.

alamb

Thank you @rluvaton - this looks good to me

I suggest we file a ticket / tickets about marking other functions as strictly_order_preserving so that we don't forget / so we can take advantage

alamb · 2026-07-27T11:32:59Z


 /// Returns true if the function preserves lexicographical ordering based on
 /// the input ordering.
+ ///


I think it would be ok to keep these descriptions short and refer readers to the very nice SortProperties description
Eg. something like
Suggested change
///
/// See [`ExprProperties::preserves_lex_ordering`] for more details

alamb · 2026-07-27T11:34:29Z

+ ///
+ /// # Examples
+ ///
+ /// * `from_unixtime(a)` returns `true`: it reinterprets the input integer
+ /// as a timestamp without changing the value, so distinct inputs yield
+ /// distinct, identically-ordered outputs.
+ /// * `floor(a)` and `date_trunc('day', a)` must return `false`: they are
+ /// monotone, but collapse distinct inputs into equal outputs.
+ /// * An addition over ordered, overflow-free inputs may return `true`
+ /// even though it does not preserve *lexicographical* ordering.
+ ///
+ /// # Definition
+ ///
+ /// Assuming the `Ordered` inputs advance simultaneously (component-wise,
+ /// i.e. all of them are sorted in the data), the output is ordered in the
+ /// same direction, equal outputs can only result from equal values of
+ /// those inputs (i.e. the mapping is one-to-one), and nulls map to nulls.
+ ///
+ /// This is not simply a stricter [`Self::preserves_lex_ordering`] - the
+ /// two properties also assume different input orderings, and with
+ /// multiple ordered inputs neither implies the other (see the examples
+ /// above). See [`ExprProperties::strictly_order_preserving`] for a
+ /// detailed comparison.
+ ///
+ /// # Relationship to [`Self::output_ordering`]
+ ///
+ /// [`Self::output_ordering`] describes *whether and in which direction*
+ /// the output is ordered, which justifies using the expression as the
+ /// **last** (or only) sort key. This property is an additional,
+ /// independent claim of injectivity that justifies keeping the **suffix**
+ /// sort keys as well: optimizers rely on it to substitute a sort key with
+ /// an expression computed from it - if data is sorted by `[x, y]`, it is
+ /// also sorted by `[expr(x), y]`, which only holds when equal `expr(x)`
+ /// values imply equal `x` values.
+ ///
+ /// When in doubt, return `false` (the default). The `inputs` properties
+ /// allow conditional answers, e.g. based on the ranges of the inputs.
+ fn strictly_order_preserving(&self, _inputs: &[ExprProperties]) -> Result<bool> {
+ Ok(false)
+ }


Similarly I think here it would be ok to point back to ExprProperties to make sure the text stays consistent
Suggested change
///
/// # Examples
///
/// * `from_unixtime(a)` returns `true`: it reinterprets the input integer
/// as a timestamp without changing the value, so distinct inputs yield
/// distinct, identically-ordered outputs.
/// * `floor(a)` and `date_trunc('day', a)` must return `false`: they are
/// monotone, but collapse distinct inputs into equal outputs.
/// * An addition over ordered, overflow-free inputs may return `true`
/// even though it does not preserve *lexicographical* ordering.
///
/// # Definition
///
/// Assuming the `Ordered` inputs advance simultaneously (component-wise,
/// i.e. all of them are sorted in the data), the output is ordered in the
/// same direction, equal outputs can only result from equal values of
/// those inputs (i.e. the mapping is one-to-one), and nulls map to nulls.
///
/// This is not simply a stricter [`Self::preserves_lex_ordering`] - the
/// two properties also assume different input orderings, and with
/// multiple ordered inputs neither implies the other (see the examples
/// above). See [`ExprProperties::strictly_order_preserving`] for a
/// detailed comparison.
///
/// # Relationship to [`Self::output_ordering`]
///
/// [`Self::output_ordering`] describes *whether and in which direction*
/// the output is ordered, which justifies using the expression as the
/// **last** (or only) sort key. This property is an additional,
/// independent claim of injectivity that justifies keeping the **suffix**
/// sort keys as well: optimizers rely on it to substitute a sort key with
/// an expression computed from it - if data is sorted by `[x, y]`, it is
/// also sorted by `[expr(x), y]`, which only holds when equal `expr(x)`
/// values imply equal `x` values.
///
/// When in doubt, return `false` (the default). The `inputs` properties
/// allow conditional answers, e.g. based on the ranges of the inputs.
fn strictly_order_preserving(&self,_inputs:&[ExprProperties]) -> Result<bool>{
Ok(false)
}
///
/// See [`ExprProperties::strictly_order_preserving`] for more details
fn strictly_order_preserving(&self,_inputs:&[ExprProperties]) -> Result<bool>{
Ok(false)
}

alamb · 2026-07-27T11:34:48Z

+ }
+
+ fn strictly_order_preserving(&self, _inputs: &[ExprProperties]) -> Result<bool> {
+ // `from_unixtime` stores the input's exact `Int64` value as a


alamb · 2026-07-27T11:51:26Z

+ let col_b = col("b", &schema)?;
+ let asc = SortOptions::default();
+ let ordering = vec![
+ PhysicalSortExpr::new(Arc::clone(&col_a), asc),


We could probably reduce the text here (and make it easier to read) maybe by creating
let ordering_a_b = PhysicalSortExpr::new(...,asc),
?

alamb · 2026-07-27T11:51:30Z

+ Arc::clone(&narrowing),
+ asc
+ )])?);
+ assert!(!eq_properties.ordering_satisfy(vec![


It does still satisfy col_a I think -- it might be nice to add an assert here that it does satisfy

…xpr::check_bigger_cast (apache#23808) (apache#23809) ## Which issue does this PR close? - Closesapache#23808. ## Rationale for this change ref. apache#23807 `CastExpr::check_bigger_cast` is used to determine whether a cast is a widening (order-preserving) conversion. Currently, it classifies `Int32 -> Float32`, `UInt32 -> Float32`, `Int64 -> Float64`, and `UInt64 -> Float64` as widening casts. However, integer-to-float conversions for 32-bit and 64-bit integers lose precision when values exceed the mantissa bit limit (24 bits for `Float32`, 53 bits for `Float64`). For example: `16_777_216_i32 as f32 == 16_777_217_i32 as f32` (both yield 16777216.0f32). Because distinct integer inputs can collapse to the same float output, these casts are not strictly 1-to-1 (injective) and can break suffix sort key ordering in multi-column ordering analysis (e.g. `[CAST(a AS Float32), b]`). ## What changes are included in this PR? - Updated `CastExpr::check_bigger_cast` to exclude precision-losing integer-to-float conversions (`Int32/UInt32 -> Float32` and `Int64/UInt64 -> Float64`). - Added unit test `test_check_bigger_cast_precision_loss` to verify precision-losing casts return `false` while exact conversions (`Int16 -> Float32`, `Int32 -> Float64`, etc.) continue to return `true`. ## Are these changes tested? Yes, new unit test `test_check_bigger_cast_precision_loss` in `cast.rs`. ## Are there any user-facing changes? No breaking API changes. Internal optimizer behavior fix.

…t whether they keep the same ordering of the input (apache#23807) ## Which issue does this PR close? - Closesapache#23798 Related to: - apache#16217 ## Rationale for this change To be able to keep the same sorting order allowing for more optimizations Now comet own `cast` implementation can be recognized as not modifying sort order in the same cases that datafusion cast does. ## What changes are included in this PR? added `strictly_order_preserving` property to `ExprProperties` + varius other places and replaced the hard coded logic for cast (`substitute_cast_ordering`) about keeping input order with more generic approach that now any expression can implement and have the same advantage of sort elimination also marked from_unixtime as keeping ordering to show a case of this optimization ## Are these changes tested? yes ## Are there any user-facing changes? yes, breaking change, added `strictly_order_preserving` property to `ExprProperties` and to `FFI_ExprProperties` this property means that given expression `f` and 2 values from the input column `a` and `b` the following variants are kept: 1. `a.cmp(b) == f(a).cmp(f(b))` 2. nulls maps to nulls Example of satisfying expression: `cast(col_a as BIGINT)` where `col_a` is `INT` it is keeping the properties Example of not satisfying: `floor` - floor can not `array_repeat(my_col, 2)` which might look like at first glance as keeping the property as well but in fact it does not. the reason is that `array_repeat(null, 2)` will output list of 2 nulls which breaks the 2nd property that nulls must be kept as nulls how to migrate: Option 1 - keeping the old behavior (safest but least performant) set `strictly_order_preserving` to false Option 2 - Using the new optimization that this opens up: set `strictly_order_preserving` only if the expression keep both variants

rluvaton added 4 commits July 22, 2026 14:12

add test that fails
15a6de3

feat: add strictly_order_preserving to ExprProperties
466f279

update doc
d60f288

update sort
9fd3665

github-actionsBot added logical-expr Logical plan and expressions physical-expr Changes to the physical-expr crates core Core DataFusion crate functions Changes to functions implementation ffi Changes to the ffi crate labels Jul 22, 2026

update comment
7305547

rluvaton changed the title ~~Debug why sort ordering get messed up~~Allow expression to report whether they keep the same ordering of the input (a.cmp(b) == f(a).cmp(f(b)) opening up for more optimizationJul 22, 2026

rluvaton force-pushed the debug-why-sort-ordering-get-messed-up branch from e0c40b1 to 7305547Compare July 22, 2026 15:13

rluvaton added the api change Changes the API exposed to users of the crate label Jul 22, 2026

rluvaton marked this pull request as ready for review July 22, 2026 15:19

github-actionsBot added the auto detected api change Auto detected API change label Jul 22, 2026

getChan reviewed Jul 22, 2026
View reviewed changes

rluvaton commented Jul 22, 2026
View reviewed changes

This was referenced Jul 22, 2026
Fix precision loss in CastExpr::check_bigger_cast for integer-to-float conversions #23808
Closed
fix: exclude precision-losing integer-to-float conversions from CastExpr::check_bigger_cast (#23808) #23809
Merged

mbutrovich self-requested a review July 24, 2026 16:29

alamb reviewed Jul 24, 2026
View reviewed changes

made repeat order preserving
1f5267a

Merge remote-tracking branch 'upstream/main' into optimize-sort-on-ad…
b5bb7ac
…d-ordering # Conflicts: # datafusion/expr-common/src/sort_properties.rs # datafusion/expr/src/udf.rs

github-actionsBot added the sqllogictest SQL Logic Tests (.slt) label Jul 25, 2026

rluvaton added 2 commits July 26, 2026 00:32

used from_unixtime
90d6a51

fixed clippy, doc and add ffi
04a6e56

Merge branch 'main' into debug-why-sort-ordering-get-messed-up
4d60d84

alamb reviewed Jul 27, 2026
View reviewed changes

alamb approved these changes Jul 27, 2026
View reviewed changes

alamb changed the title ~~Allow expression to report whether they keep the same ordering of the input (a.cmp(b) == f(a).cmp(f(b))) opening up for more optimization~~ScalarUdfImpl::strictly_order_preserving: Allow expression to report whether they keep the same ordering of the inputJul 27, 2026

code review changes
ad7d27b

rluvaton added this pull request to the merge queue Jul 27, 2026

Merged via the queue into apache:main with commit 1c3232cJul 27, 2026
41 checks passed

rluvaton deleted the debug-why-sort-ordering-get-messed-up branch July 27, 2026 13:26

rluvaton mentioned this pull request Jul 27, 2026
Pass over udfs/physical expr that strictly_order_preserving and mark them as such #23920
Open

	///
	/// See [`ExprProperties::preserves_lex_ordering`] for more details

Uh oh!

Conversation

rluvaton commented Jul 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

github-actionsBot commented Jul 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rluvaton commented Jul 22, 2026

Uh oh!

getChanJul 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Jul 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

alamb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rluvaton commented Jul 25, 2026

Uh oh!

rluvaton commented Jul 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rluvaton commented Jul 26, 2026

Uh oh!

alamb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

rluvaton commented Jul 22, 2026•
edited
Loading

github-actionsBot commented Jul 22, 2026•
edited
Loading

getChanJul 22, 2026•
edited
Loading

codecov-commenter commented Jul 22, 2026•
edited
Loading

rluvaton commented Jul 25, 2026•
edited
Loading