[pull] main from apache:main#191
Merged
Merged
Conversation
… hashing work during physical planning. (#22175) ## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes #123` indicates that this PR will close issue #123. --> - Closes #22173. ## Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> Explained in issue ## What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> 1. Removed derived Hash & Eq 2. implemented manual Hash & Eq 3. manual impl excludes redudant & recursive hash `eval_method` field ## Are these changes tested? <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> A unit test was added ## Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> Pathologically nested CASE/WHEN queries will plan significantly faster. <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes #123` indicates that this PR will close issue #123. --> - Closes #22121 ## Rationale for this change `array_replace.rs` already covers `array_replace`, `array_replace_n`, and `array_replace_all` through the public UDF path, and includes the relevant int64 benchmark sizes plus broader nested, string, boolean, and fixed-size-binary cases. Keeping both benchmark targets would duplicate maintenance and make ownership unclear. <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> ## What changes are included in this PR? This removes the stale `array_expression` benchmark target. The dedicated `array_replace` benchmark remains the single benchmark owner for array replacement performance. <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> ## Are these changes tested? Yes, locally <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> ## Are there any user-facing changes? No <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. -->
## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes #123` indicates that this PR will close issue #123. --> - Closes #22113 . ## Rationale for this change `RANGE` window frames with a `DECIMAL` `ORDER BY` column crash at runtime: ```sql SELECT COUNT(*) OVER ( PARTITION BY 1 ORDER BY cast(1 as decimal(10, 0)) DESC RANGE BETWEEN CURRENT ROW AND 1 FOLLOWING ) FROM (SELECT 1); -- Internal error: Uncomparable values: Decimal128(Some(0),11,0), Decimal128(Some(1),10,0). ``` Frame-bound arithmetic (`value ± delta`) widens the decimal result precision by 1 (`Decimal(10,0) ± Decimal(10,0) → Decimal(11,0)`). `search_in_slice` then compares the widened target against the original `ORDER BY` column, and `ScalarValue::partial_cmp` rejects decimals whose precision differs — even when the scale matches and the underlying integer representation is directly comparable. That precision-equality gate is also inconsistent with SQL semantics: `DEC(10,0) 1` and `DEC(20,0) 1` represent the same number and should compare equal. ## What changes are included in this PR? **`datafusion/common/src/scalar/mod.rs`** - `ScalarValue::partial_cmp` for `Decimal32` / `Decimal64` / `Decimal128` / `Decimal256`: compare underlying values whenever scales match, regardless of declared precision. Different scales still return `None` (rescaling would be required). **`datafusion/sqllogictest/test_files/window.slt`** - Regression block covering the reporter query verbatim plus `ASC`/`DESC` × `PRECEDING`/`FOLLOWING`, symmetric `N PRECEDING AND N FOLLOWING`, and a non-zero-scale `DECIMAL(10,2)` case over multi-row partitions.
## Which issue does this PR close? Part of #21172 ## Rationale for this change This has been pulled out from main lambda PR to reduce it's size. Currently, the `LambdaVariable` field is an `Option<FieldRef>` but must be set manually for `expr_api` users (see below, passing `None` would result in planning/execution errors). This is similar to `Expr::Placeholder` field and its helper `Expr::infer_placeholder_types` https://github.com/apache/datafusion/blob/7f2f78d48b6d3d6aee2ce2fd29910bb4c11b1012/datafusion/functions-nested/src/array_transform.rs#L328-L341 Now it can be omitted and later resolved by the new helpers: https://github.com/apache/datafusion/blob/7c266c10e806cf87edfe5a2eccccccf639fdb2fe/datafusion/functions-nested/src/array_transform.rs#L326-L330 ## What changes are included in this PR? This PR adds the method `resolve_lambda_variables` to `Expr` and `LogicalPlan` to automatically resolve all variables of the given expr or logical plan. Nothing changes for sql planning ## Are these changes tested? There's a unit test which should cover all edge cases. Is not trivial to test via sqllogictests because sql planning produces already resolved lambda variables. ## Are there any user-facing changes? New methods added only
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )