[pull] main from apache:main by pull[bot] · Pull Request #123 · buraksenn/datafusion

pull · 2026-04-20T18:33:32Z

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 : )

@Dandandan

## Which issue does this PR close? - Closes #20529 - Closes #20820 ## Rationale for this change This PR finally enables dynamic work scheduling in the FileStream (so that if a task is done it can look at any remaining work) This improves performance on queries that scan multiple files and the work is not balanced evenly across partitions in the plan (e.g. we have dynamic filtering that reduces work significantly) It is the last of a sequence of several PRs: - #21342 - #21327 - #21340 ## What changes are included in this PR? 1. Add shared state across sibling FileStream's and the wiring to connect them 2. Sibling streams put their file work into a shared queue when it can be reordered 3. Add a bunch of tests sjpw Note there are a bunch of other things that are NOT included in this PR, including 1. Trying to limit concurrent IO (this PR has the same properties as main -- up to one outstanding IO per partition) 2. Trying to issue multiple IOs by the same partition (aka to interleave IO and CPU work more) 4. Splitting files into smaller units (e.g. across row groups) As @Dandandan proposes below, I expect we can work on those changes as follow on PRs. ## Are these changes tested? Yes by existing functional and benchmark tests, as well as new functional tests ## Are there any user-facing changes? Yes, faster performance (see benchmarks): #21351 (comment) --------- Co-authored-by: Oleks V <[email protected]>

## Which issue does this PR close?  - Related to #21635. ## Rationale for this change Upon releasing 53.0.0 and 53.1.0 I found some steps not clear or misleading, I tried to clarify steps based on most recent experience  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

…pache#21708) ## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes #. ## Rationale for this change  One test case in `datafusion-cli` crate is failing locally if you run all tests through `cargo nextest run`, but passes for `cargo test` ``` FAIL [ 0.375s] datafusion-cli::cli_integration cli_explain_environment_overrides ``` The reason is `nextest` triggers a different build graph, which enforces a feature flag in `serde_json` dependency. This PR enforces this feature in the `dev-dependencies` in `datafusion-cli` crate, so the test become deterministic under different test setup. apache#21502 Fixed a similar issue, and also explains why not enabling it in the global dependencies inside `Cargo.toml` ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

@gabotechs

…pache#21769) ## Which issue does this PR close?  - Closes #. ## Rationale for this change Initially posted by @gabotechs in apache#21013 (comment)  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

…ache#21561) ## Which issue does this PR close? Evaluate perf with group accumulators for count distinct  - Closes #. Related : apache#21575 benchmark PR ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

… smaller int datatypes (apache#21453) ## Which issue does this PR close?  - Closes apache#1109 ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes #. ## Rationale for this change  Follow-up to a review comment in : apache#21713 (comment) Not a bug fix, this PR tries to be more defensive and catch potential bugs. Before, when you write a spill file from a `SpillManager`, then read with another `SpillManager` of different schema, it would succeed. This is not a expected use pattern, an error will get propagated to the caller, and become harder to debug. This PR validates the schema when reading the first batch, and fail fast if the schema does not match. Note it only validates the schema, if two `SpillManager`s with the same schema do read and write, it's still allowed, but this is not a expected use pattern. Validating this case requires assigning `SpillManager` UID, and add that to the Arrow IPC file metadata, can be tricky, so leave this as TODO for simplicity. ## What changes are included in this PR?  ## Are these changes tested?  UTs ## Are there any user-facing changes?  No  --------- Co-authored-by: Oleks V <[email protected]>

…#21669) ## Which issue does this PR close?  - Closes apache#18886 - Previous iteration: apache#18884 ## Rationale for this change  More support for listview types in the codebase ## What changes are included in this PR?  Added `ListView` and `LargeListView` to `ScalarValue` with all accompanying changes Support `ListView` and `LargeListView` in proto, both for the arrow datatype & the newly introduced scalarvalue variants. ## Are these changes tested?  Yes, added tests ## Are there any user-facing changes?  No  --------- Co-authored-by: Khanh Duong <[email protected]> Co-authored-by: Andrew Lamb <[email protected]>

…#21762) ## Which issue does this PR close?  - None ## Rationale for this change  Sometimes, when an `ExecutionPlan` implementation is complex, different metrics are collected from different structs that compose the whole execution plan. These metrics need to eventually be served from the single entrypoint `ExecutionPlan::metrics()` or `DataSource::metrics()`, and the current api does not have good methods for merging several `ExecutionPlanMetricsSet` coming from different sources into a single one. ## What changes are included in this PR?  Add some basic conversion and iteration methods for `MetricsSet` and `ExecutionPlanMetricsSet`, in order to improve ergonomics around these structs. ## Are these changes tested?  This is purely just basic std trait implementations and method exposure, so as long as the code compiles, I don't think it needs further tests. ## Are there any user-facing changes? People will see some more available methods in the `MetricsSet` and `ExecutionPlanMetricsSet` structs for ergonomics.

@viirya

…#21742) ## Which issue does this PR close?  - Closes #. ## Rationale for this change  ### Background apache#21448 introduced memory-limited execution for NLJ (thanks to @viirya). The idea is: 1. Load the build (left) side of the NLJ until the memory limit is reached. 2. Probe the right side and complete the join for the current buffered build-side chunk. 3. Load the next chunk of the build side and repeat the right-side scan until all data is processed. To support repeated probing of the right side, input batches are spilled to disk during the first pass. In subsequent passes, input is read directly from the spill. This avoids re-evaluating potentially expensive pipelines (e.g., Parquet decoding + filtering), making repeated probes both memory-efficient and fast. ### This PR This PR extracts the spill-backed replayable stream into a separate module to simplify the NLJ implementation. Although the lines of code increase, the new module provides a clearer interface and I think it's easier to maintain. Additionally, this utility may be useful elsewhere. I have seen a similar pattern in SedonaDB for memory-limited spatial joins. ## What changes are included in this PR?  - Introducing `ReplayableStreamSource` for the above purpose - Refactor NLJ logic with `ReplayableStreamSource` ## Are these changes tested?  UTs, also covered by existing memory-limited NLJ test ## Are there any user-facing changes?   No --------- Co-authored-by: Martin Grigorov <[email protected]>

Hi! I open this small PR with some fixes I found while reading through the examples. I haven't created an issue as these are tiny changes. Thanks for your time! ## Which issue does this PR close?  No related issue ## Rationale for this change  I found some small mistakes on comments on the query_planning example ## What changes are included in this PR?  Small comment corrections ## Are these changes tested?  No need ## Are there any user-facing changes?   No

## Which issue does this PR close?  N/A ## Rationale for this change  Some PRs are being omitted from stale check because they were in a cache, and the workflow appears to not have permission to delete cache so they are forever stuck as unprocessed. For example in this run: https://github.com/apache/datafusion/actions/runs/24756695077/job/72431314533 Seeing this in logs: ``` [apache#20473] issue skipped due being processed during the previous run [apache#20460] pull request skipped due being processed during the previous run [apache#20448] issue skipped due being processed during the previous run [apache#20443] issue skipped due being processed during the previous run [apache#20435] issue skipped due being processed during the previous run [apache#20418] issue skipped due being processed during the previous run [apache#20417] pull request skipped due being processed during the previous run [apache#20416] pull request skipped due being processed during the previous run [apache#20403] pull request skipped due being processed during the previous run ``` And at the end we see this warning: ``` Warning: Error delete _state: [403] Resource not accessible by integration - https://docs.github.com/rest/actions/cache#delete-github-actions-caches-for-a-repository-using-a-cache-key ``` stale workflow uses a cache in case it hits the `operations-per-run` limit meant to prevent API rate limiting (we have default of 30), so it seems we previously hit this limit and some issues/PRs were cached, and have never been uncached since so are never processed again. See: https://github.com/actions/stale#operations-per-run ## What changes are included in this PR?  Give permission to stale workflow to run github actions (like delete cache). See recommended permissions: https://github.com/actions/stale#recommended-permissions ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - From this discussion: apache#19711 (comment) ## Rationale for this change  In above PR we didn't enable a test because upstream arrow-rs had a panic bug. This is now fixed: - apache/arrow-rs#9144 So now we can enable this test again to assert expected error. ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes apache#19782 ## Rationale for this change  We've landed various PRs required to support aggregating on list views (both upstream in arrow-rs and here in datafusion) so now this simple aggregation test succeeds; adding it to the slt suite. ## What changes are included in this PR?  Add aggregation test for listviews ## Are these changes tested?  Yes ## Are there any user-facing changes?  No

…he#21773) ## Which issue does this PR close?  - Closes apache#19798 ## Rationale for this change  Upstream issue fixed, re-enable test - apache/arrow-rs#9227 ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Part of apache#20585. ## Rationale for this change `substr_index` is part of the Utf8View epic. This function was still missing the Utf8View optimization path, and it also did extra work when delimiter and count were constant scalars. This PR adds the same kind of optimization used in similar string work and includes benchmark coverage.  ## What changes are included in this PR? - Return the input string type directly, including `Utf8View`. - Add a zero-copy `Utf8View` path for `substr_index`. - Add a scalar fast path when delimiter and count are constant. - Keep the hot path specialized after checking a cleaner shared-helper version and benchmarking it. - Add SQL coverage for `Utf8View` type and value results. - Add unit tests for the scalar fast path, sliced `Utf8View` arrays, and the unchanged original-view case. - Extend the benchmark to cover `Utf8`, `Utf8View`, array arguments, scalar delimiter/count, and positive and negative counts.  ## Are these changes tested? Yes  ## Are there any user-facing changes? No

## Which issue does this PR close?  - Closes apache#21279 - Closes apache#21281 ## Rationale for this change  Keep dependencies up to date. ## What changes are included in this PR?  We used to use `Digest` from `blake2`, which was a common dependency used by `md5` and `sha2`; however `blake2` doesn't have a `0.11.0` release so we were blocked because of incompatible dependencies when trying to upgrade `sha2` or `md5`. Fix code to use their own `Digest` (e.g. `md5::Digest`, `sha2::Digest`) instead of relying on `blake2::Digest` which should prevent such issues from occurring again and allows us to bump their versions independently. ## Are these changes tested?  Existing tests. ## Are there any user-facing changes?  No.

## Which issue does this PR close?  - Closes apache#21747 ## Rationale for this change datafusion did not have a CI check for broken links in markdown content, docs workflows build and deploy docs, and dev checks formatting and spelling, but none of them validate link targets. This pr adds a dedicated link check for internal markdown links so broken references fail early in PRs. I kept the scope internal-only to avoid flaky CI failures from external websites and rate limits. Rust doc comments remain covered by the existing rustdoc CI job.  ## What changes are included in this PR? - Added a new Dev workflow job, **Check Markdown Links**, in `dev.yml`. - Added `LYCHEE_VERSION` pin in `tool_versions.sh`. - Added `markdown_link_check.sh` to run lychee on the selected markdown paths. - Added `lychee.toml` with internal-link policy and exclusions. - Added check markdown links to required status checks in `.asf.yaml`. - Updated contributor testing docs with the new local command and scope note. - Fixed internal markdown links that failed under the new check in: - `roadmap.md` - `49.0.0.md` - `overview.md` - `dataframe.md` - `format_options.md`  ## Are these changes tested? Yes, - `python3 ci/scripts/check_asf_yaml_status_checks.py` passed. - `bash -n ci/scripts/markdown_link_check.sh` passed. - `bash ci/scripts/markdown_link_check.sh` passed with 0 errors. - `cargo fmt --all --check` passed. OK: All 5 required_status_checks match existing GitHub Actions jobs. 🔍 12824 Total (in 0s) ✅ 490 OK 🚫 0 Errors 👻 12334 Excluded  ## Are there any user-facing changes? No, There is one contributor-facing CI change: PRs now fail when internal markdown links break in the checked markdown files.   --------- Co-authored-by: Oleks V <[email protected]>

…ache#21725) ## Which issue does this PR close?  - Closes apache#16894 ## What changes are included in this PR? - User-visible struct-UNNEST columns no longer expose `__unnest_placeholder`. - Internal Unnest planning still uses placeholders. - This adds a final Projection layer in explain plans wherever struct UNNEST output is published.  ## Are these changes tested? Yes.  ## Are there any user-facing changes? Yes. The aliases of unnested columns will be changed.   --------- Co-authored-by: Andrew Lamb <[email protected]>

…onger maintained (apache#21030) ## Which issue does this PR close?  - Closes apache#20863 ## Rationale for this change  ## What changes are included in this PR? - Replace abi_stable types with stabby equivalents: - `RVec` -> `stabby::vec::Vec` - `RString` -> `stabby::string::String` - Add custom `FFI_Option` and `FFI_Result` types since we have raw pointers and self referential pointers which can't implement `IStable` trait needed for stabby - Rename `macros: rresult` → `sresult`, `rresult_return `→ `sresult_return` - Fix library path detection for debug/release builds in the example loader - Update README  ## Are these changes tested? Yes . With df python bindings on DF 52 release  ## Are there any user-facing changes?

…cans (apache#20844) ## Which issue does this PR close?  I figured it will be easier to submit PR right away as change doesn't look controversial. I'm happy to create an issue and link it here if you'd prefer. ## Rationale for this change  So short story is: in another project we'd like to use DataFusion's to "build" operations on data and then submit resulting logical plan _somewhere_ to execute (likely not using DF to actually execute the query). Since those plans never meant to be executed by DF we use `EmptyTable` as a base to bring schema to DF without any actual data. `EmptyTable` scans not being serializable prevents us from sending those plans to Python or over the wire. I believe this change makes datafusion's LogicalPlan more portable and more usable outside of datafusion's query executor. Longer story: [VegaFusion](https://github.com/vega/vegafusion) does server-side aggregation for Vega charts and is powered by DataFusion. We recently added option to [use custom query/plan executors](vega/vegafusion#573), which allows user to pass a schema (without data) to VegaFusion which will add all necessary aggregations (but not execute them) and return a logical plan to user. They can then outsource this plan to custom query executor (e.g. Spark). This is already implemented and works. However, since VegaFusion is most commonly used through Python bindings, we'd like to expose this API to Python too (and additionally as part of gPRC API too) , which requires serializing built plans to protobuf. Currently we use `EmptyTable` to bring schema without any data to DataFusion. But since it can't be converted to protobuf, we're unable to expose this API. We considered providing custom decoder/encoder, but that would work only for gRPC case, but not Python as datafusion-python doesn't allow to provide custom decoder as far as I understand. ## What changes are included in this PR?  * Moved `EmptyTable` from `datafusion-core` into `datafusion-catalog` and added backwards compatibility re-export (following pattern for other table providers moved earlier) * Added new `EmptyTableScanNode` to protobuf definitions * Added encoding and decoding for new entity into `AsLogicalPlan for LogicalPlanNode` implementation ## Are these changes tested?  I added two roundtrip tests for the new node ## Are there any user-facing changes?  `EmptyTable` can be imported from `datafusion-catalog` crate now, but old crate (`datafusion-core`) still re-exports it, so this shouldn't be breaking change  P.S. Just to be explicit, code itself was written mostly by LLM (as I'm not that proficient in Rust yet). I did review and test it though

## Which issue does this PR close?  N/A ## Rationale for this change  <img width="302" height="45" alt="image" src="https://github.com/user-attachments/assets/fed0ded5-5ef5-4e10-9bd6-bb3391470ee7" /> Lets work on getting this number down to 0 ## What changes are included in this PR?  Fix some permissions to be minimum required in GH action workflows ## Are these changes tested?  All affected workflows were run on this commit: apache@48ffe3f - Since some workflows trigger on certain changes only - large files successful: https://github.com/apache/datafusion/actions/runs/24923629680/job/72989644694?pr=21838 - docs pr successful: https://github.com/apache/datafusion/actions/runs/24923629679/job/72989644704?pr=21838 - dependencies: - circular check successful: https://github.com/apache/datafusion/actions/runs/24923629662/job/72989644657?pr=21838 - unused check successful: https://github.com/apache/datafusion/actions/runs/24923629662/job/72989644656?pr=21838 - audit successful: https://github.com/apache/datafusion/actions/runs/24923629664/job/72989644667?pr=21838 - dev: - license check successful: https://github.com/apache/datafusion/actions/runs/24923629678/job/72989644714?pr=21838 - prettier successful: https://github.com/apache/datafusion/actions/runs/24923629678/job/72989644708?pr=21838 - asf yaml check successful: https://github.com/apache/datafusion/actions/runs/24923629678/job/72989644706?pr=21838 - typos successful: https://github.com/apache/datafusion/actions/runs/24923629678/job/72989644701?pr=21838 ## Are there any user-facing changes?   --------- Co-authored-by: Andrew Lamb <[email protected]>

## Which issue does this PR close?  N/A ## Rationale for this change  Looking to push a PR on optimizing `array_remove` later; discovered we were lacking coverage for `array_remove_n` and `array_remove_all` variants, as well as nested types. In the process of adding them, decided to also do some cleanup of the benchmarks, specifically to generate data in a more targeted fashion suitable to what we're benchmarking in the functions (removing a specified needle from a haystack). ## What changes are included in this PR?  - Refactor functions used to create test data, unifying where possible - Remove f64, decimal & binary benchmarks - Add nested i64 (list<list<i64>>) benchmarks - Add remove_n & remove_all benchmarks for i64 and nested i64 ## Are these changes tested?  Benchmark only changes. ## Are there any user-facing changes?  No.

## Which issue does this PR close?  - Closes #. Followup on apache#21679 (comment) ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?   --------- Co-authored-by: Raz Luvaton <[email protected]>

## Which issue does this PR close?  - Part of apache#21777 ## Rationale for this change  First step in supporting `ListView` types in UDFs. Previously the UDFs would error if trying to pass a `ListView` type to nested UDFs. Now we can pass in `ListView` inputs and they are cast to `List`/`LargeList` (similar to `FixedSizeList` if that coercion mode is enabled). ## What changes are included in this PR?  In type coercion, for array signatures automatically coerce any `ListView`/`LargeListView` types to `List`/`LargeList` respectively. Also add `ListView` support to various array util functions. ## Are these changes tested?  Added SLTs. ## Are there any user-facing changes?  No.

## Which issue does this PR close?  - Closes #. ## Rationale for this change  After apache#19759, all the methods of a `MemoryReservation` take &self instead of &mut self, so no need to hide a `SharedMemoryReservation` behind a Mutex. ## What changes are included in this PR?  Remove an unnecessary Mutex ## Are these changes tested?  By existing unit tests ## Are there any user-facing changes? No

## Which issue does this PR close?  Informs: datafusion-contrib/datafusion-distributed#180 Closes: apache#20418 ## Rationale for this change  Consider you have a plan with a `HashJoinExec` and `DataSourceExec` ``` HashJoinExec(dynamic_filter_1 on a@0) (...left side of join) ProjectionExec(a := Column("a", source_index)) DataSourceExec ParquetSource(predicate = dynamic_filter_2) ``` You serialize the plan, deserialize it, and execute it. What should happen is that the dynamic filter should "work", meaning: 1. When you deserialize the plan, both the `HashJoinExec` and `DataSourceExec` should have pointers to the same `DynamicFilterPhysicalExpr` 2. The `DynamicFilterPhysicalExpr` should be updated during execution by the `HashJoinExec` and the `DataSourceExec` should filter out rows This does not happen today for a few reasons, a couple of which this PR aims to address 1. `DynamicFilterPhysicalExpr` is not survive round-tripping. The internal exprs get inlined (ex. it may be serialized as `Literal`) due to the `PhysicalExpr::snapshot()` API 2. Even if `DynamicFilterPhysicalExpr` survives round-tripping, the one pushed down to the `DataSourceExec` often has different children. In this case, you have two `DynamicFilterPhysicalExpr` which do not survive deduping, causing referential integrity to be lost. ## What changes are included in this PR?  This PR aims to fix those problems by: 1. Removing the `snapshot()` call from the serialization process 2. Adding protos for `DynamicFilterPhysicalExpr` so it can be serialized and deserialized 3. Removing `Arc`-based deduplication. We now only dedupe on `expression_id` if the `PhysicalExpr` reports a `expression_id`. After this change, only `DynamicFilterPhysicalExpr` reports an `expression_id` to be deduped. 4. `expression_id` is now just a random u64. Since a given query likely only has a few `DynamicFilterPhysicalExpr` instances, the odds of a collision are very low 5. There's no need for a `DedupingSerializer` anymore since the `expression_id` is already stored in the dynamic filter proto itself Future work: 1. Serialize dynamic filters in `HashJoinExec`, `AggregateExec` and `SortExec` 2. Add tests which actually execute plans after deserialization and assert that dynamic filtering is functional 3. Add proto converters to the `PhysicalExtensionCodec` trait so implementors can utilize deduping logic ## Are these changes tested? - adds tests which roundtrip dynamic filters and assert that referential integrity is maintained - removes tests that test `Arc`-based deduplication and session id rotation since we don't support that anymore ## Are there any user-facing changes? - The default codec does not call `snapshot()` on `PhysicalExpr` during serialization anymore. This means that `DynamicFilterPhysicalExpr` are now serialized and deserialized without snapshotting. - All `PhysicalExpr` are not deduped anymore. Only `DynamicFilterPhysicalExpr` is --------- Co-authored-by: Dmitrii Blaginin <[email protected]>

## Which issue does this PR close?  - Closes #. ## Rationale for this change Fix negative cases with `substring`, some tests were incorrect  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes #. ## Rationale for this change Followup on apache#21978  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes #. ## Rationale for this change Currently if DATA_DIR is set for bench.sh it is not respected for sql benchmarks and defaults to benchmarks/data ## What changes are included in this PR? Updated tpch benchmarks to respect DATA_DIR defaulting to 'data' (in benchmarks/) ## Are these changes tested? Yes, unit test + manual testing. ## Are there any user-facing changes? No.

## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR?  Benchmark for apache#21948 ## Are these changes tested?  ## Are there any user-facing changes?

…e#21833) ## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR? Previously RIGHT/FULL/RIGHT SEMI/RIGHT ANTI/RIGHT MARK joins were excluded from the memory-limited (multi-pass) fallback path because they need to track which right rows have been matched across all left chunks. They would OOM instead of spilling. Now all join types support the fallback: - A global right bitmap (Vec<BooleanBuffer>, indexed by right batch sequence number) accumulates matches across all left chunk passes. ReplayableStreamSource guarantees consistent batch boundaries across passes, so batch sequence numbers are stable. - In memory-limited mode, EmitRightUnmatched merges the current batch's bitmap into the global accumulator (bitwise OR) instead of emitting unmatched rows immediately. - After the last left chunk, a new state EmitGlobalRightUnmatched replays the right side one more time and uses the accumulated bitmap to emit unmatched right rows correctly. Single-pass behavior is unchanged: the global bitmap path is only active when is_memory_limited() is true. Co-authored-by: Claude Code ## Are these changes tested?  Unit tests and e2e tests ## Are there any user-facing changes?   No

…sks rather than `Vec<bool>` (apache#21886) ## Which issue does this PR close?  - Closes apache#18676 ## Rationale for this change  Using bitmasks rather than `Vec<bool>` ## What changes are included in this PR?  - Uses arrow's `BooleanBufferBuilder` with `as_slice_mut()` + `apply_bitwise_binary_op` for the primitive non-nullable path ## Are these changes tested?  ## Are there any user-facing changes?   No --------- Co-authored-by: Andrew Lamb <[email protected]>

…1979) ## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR? Apache Spark substring also supports Binary type which is currently missing, adding Binary support and tests  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close?  - Closes apache#17152 ## Rationale for this change  - [x] 1. `Vec<Option<String>>` extra allocations - Resolved in apache#20635 by using `StringBuilder` - [ ] 2. Per-row cast on fallback - Will be resolved in this PR ```rust // When `Date32` formatting fails (due to time specifiers), // the code called cast individually for each row instead of converting the entire array let date64_value = cast(&data_array.slice(idx, 1), &Date64)?; ``` ## What changes are included in this PR?  Cast the entire Date32 array to Date64 once on first failure, instead of per-row ```rust cast(data_array.as_ref(), &Date64 ``` ## Are these changes tested?  Yes - Add 2 benchmarks: - `Date32 + datetime` patterns (all rows trigger the fallback) - `Date32 + mixed patterns` (roughly half do) ```bash ┌─────────────────────────────────────┬───────────────────┬───────────┐ │ Benchmark │ Format │ Change │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ array_date_only_patterns_1000 │ array, date-only │ No change │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ array_datetime_patterns_1000 │ array, datetime │ -3.21% │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ array_mixed_patterns_1000 │ array, mixed │ +1.41% │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ scalar_date_only_pattern_1000 │ scalar, date-only │ No change │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ scalar_datetime_pattern_1000 │ scalar, datetime │ No change │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ array_date32_datetime_patterns_1000 │ array, datetime │ -20.24% │ ├─────────────────────────────────────┼───────────────────┼───────────┤ │ array_date32_mixed_patterns_1000 │ array, mixed │ -15.74% │ └─────────────────────────────────────┴───────────────────┴───────────┘ ``` <details> <summary>Detail</summary> ```bash cargo bench --bench to_char Compiling datafusion-functions v53.1.0 (/Users/qmac/Documents/GitHub/datafusion/datafusion/functions) Finished `bench` profile [optimized] target(s) in 1m 10s Running benches/to_char.rs (target/release/deps/to_char-d2acea4b7a3e2fba) Gnuplot not found, using plotters backend Benchmarking to_char_array_date_only_patterns_1000: Warming up for 3.00Benchmarking to_char_array_date_only_patterns_1000: Collecting 100 sampto_char_array_date_only_patterns_1000 time: [104.01 µs 104.37 µs 104.74 µs] change: [−0.5692% +0.3244% +1.0788%] (p = 0.47 > 0.05) No change in performance detected. Found 3 outliers among 100 measurements (3.00%) 1 (1.00%) low mild 2 (2.00%) high mild Benchmarking to_char_array_datetime_patterns_1000: Warming up for 3.000Benchmarking to_char_array_datetime_patterns_1000: Collecting 100 samplto_char_array_datetime_patterns_1000 time: [165.96 µs 166.43 µs 166.94 µs] change: [−4.1660% −3.2055% −2.3626%] (p = 0.00 < 0.05) Performance has improved. Found 6 outliers among 100 measurements (6.00%) 2 (2.00%) low mild 3 (3.00%) high mild 1 (1.00%) high severe Benchmarking to_char_array_mixed_patterns_1000: Collecting 100 samples to_char_array_mixed_patterns_1000 time: [139.58 µs 140.02 µs 140.49 µs] change: [+1.0116% +1.4122% +1.8178%] (p = 0.00 < 0.05) Performance has regressed. Found 3 outliers among 100 measurements (3.00%) 1 (1.00%) low mild 2 (2.00%) high mild Benchmarking to_char_scalar_date_only_pattern_1000: Warming up for 3.00Benchmarking to_char_scalar_date_only_pattern_1000: Collecting 100 sampto_char_scalar_date_only_pattern_1000 time: [60.073 µs 63.184 µs 66.309 µs] change: [−4.0228% +0.6839% +6.1581%] (p = 0.79 > 0.05) No change in performance detected. Benchmarking to_char_scalar_datetime_pattern_1000: Warming up for 3.000Benchmarking to_char_scalar_datetime_pattern_1000: Collecting 100 samplto_char_scalar_datetime_pattern_1000 time: [117.65 µs 124.76 µs 131.84 µs] change: [−3.3009% +2.6889% +8.6148%] (p = 0.37 > 0.05) No change in performance detected. Found 30 outliers among 100 measurements (30.00%) 16 (16.00%) low mild 14 (14.00%) high mild Benchmarking to_char_array_date32_datetime_patterns_1000: Warming up foBenchmarking to_char_array_date32_datetime_patterns_1000: Collecting 10to_char_array_date32_datetime_patterns_1000 time: [289.67 µs 290.77 µs 291.88 µs] change: [−20.661% −20.240% −19.863%] (p = 0.00 < 0.05) Performance has improved. Benchmarking to_char_array_date32_mixed_patterns_1000: Warming up for 3Benchmarking to_char_array_date32_mixed_patterns_1000: Collecting 100 sto_char_array_date32_mixed_patterns_1000 time: [194.47 µs 195.28 µs 196.11 µs] change: [−16.230% −15.738% −15.285%] (p = 0.00 < 0.05) Performance has improved. ``` </details> ## Are there any user-facing changes?   No --------- Co-authored-by: Kumar Ujjawal <[email protected]>

## Which issue does this PR close?  - N/A ## Rationale for this change  - Building the `datafusion-spark` crate in isolation, e.g. `cargo clippy -p datafusion-spark` fails as indicated by apache#21043 ```Shell error[E0433]: failed to resolve: use of unresolved module or unlinked crate `datafusion` --> datafusion/spark/src/function/string/is_valid_utf8.rs:19:5 | 19 | use datafusion::logical_expr::{ColumnarValue, Signature, Volatility}; | ^^^^^^^^^^ use of unresolved module or unlinked crate `datafusion` ``` ## What changes are included in this PR?  Fix import statement. No code changes. ## Are these changes tested?  Yes, building `datafusion-spark` crate works now. ## Are there any user-facing changes?   N/A

## Which issue does this PR close?  - Closes apache#21943. ## Rationale for this change `parse_url` in the Spark function library did not match Spark for some empty path URL cases. In particular, absolute URLs with no explicit path were treated as if they had `/` because the URL parser normalizes the path. Also handles - `parse_url(..., 'PATH')` now returns `/` for an explicit root path like `http://example.com/`. - `parse_url(..., 'QUERY', key)` now returns the raw query value, so percent-encoded values like `x%20y` are not decoded to `x y`.  ## What changes are included in this PR? This PR keeps the existing URL parser, but adjusts `FILE` extraction so parser-normalized `/` is treated as empty only when the original URL had no path after the authority. It also adds regression coverage for `parse_url` and `try_parse_url`, including the boundary between a missing path and an explicit root path.  ## Are these changes tested? Yes  ## Are there any user-facing changes? `parse_url` and `try_parse_url` now match Spark more closely for empty path FILE results. There is no public API change.

## Which issue does this PR close? This PR provides the benchmarks mentioned in apache#7647 & apache#9017  - Works towards closing apache#7647. ## Rationale for this change Currently the benchmark suite doesn't have any dictionary-encoded tables with aggregations performed on them. This makes it difficult to prove performance improvements, for example, a separate PR I'm working on (apache#21765) is hard to validate because the existing benchmarks don't exercise this path. This PR attempts to close that gap.  ## What changes are included in this PR? Adds a new dict benchmark to dfbench that measures group-by performance on dictionary-encoded columns across varying cardinality (5/10/25%), null rates (0/15%), and value types (Utf8 and List<Utf8>), covering both single and multi-column group-by scenarios.  ## Are these changes tested? --  ## Are there any user-facing changes? no   --------- Co-authored-by: Dmitrii Blaginin <[email protected]> Co-authored-by: Kumar Ujjawal <[email protected]>

## Which issue does this PR close?  - Closes apache#22016 ## Rationale for this change  - `CoalescePartitionsExec` uses `RecordBatchReceiverStreamBuilder` which was holding to an Arc ref of the input plan, until the stream was done. - More details in the issue. ## What changes are included in this PR?  - Now we drop the input plan early. - The only other usage of `input` was in debug prints, to display the input plan. We now take the display string early, but only when debug logging is enabled. ## Are these changes tested?  - Added a test that ensures this. Verified that the test fails without the fix. The reproducer (Samyak2#1) before the fix: ``` repartition_task_group=0 input_partition=0 kind=pull_from_input drop_elapsed_ms=68 repartition_task_group=1 input_partition=0 kind=pull_from_input drop_elapsed_ms=80 repartition_task_group=1 input_partition=1 kind=pull_from_input drop_elapsed_ms=85 output_partitions=32 input_rows_per_partition=1024000 all_repartition_operator_drop_elapsed_ms=80 all_repartition_task_drop_elapsed_ms=85 all_observed_drop_elapsed_ms=85 ``` ~85ms to cancel repartition tasks. After fix: ``` repartition_task_group=0 input_partition=0 kind=pull_from_input drop_elapsed_ms=16 repartition_task_group=1 input_partition=0 kind=pull_from_input drop_elapsed_ms=0 repartition_task_group=1 input_partition=1 kind=pull_from_input drop_elapsed_ms=0 output_partitions=32 input_rows_per_partition=1024000 all_repartition_operator_drop_elapsed_ms=0 all_repartition_task_drop_elapsed_ms=16 all_observed_drop_elapsed_ms=16 ``` ~16ms to cancel repartition tasks. ## Are there any user-facing changes?   CPU/memory gets released earlier on cancellation --------- Co-authored-by: Kumar Ujjawal <[email protected]>

## Which issue does this PR close? Part of https://github.com/apache/datafusion/issues/15914 - Closes apache#20860  ## Rationale for this change Spark compatible semantics for `floor` function  ## What changes are included in this PR? Implements SparkFloor UDF with Spark-compatible return types: - Float/Integer inputs -> Int64 - Decimal128(p, s) -> Decimal128(p-s+1, 0)  ## Are these changes tested? Yes . Added unit tests and SLT tests  ## Are there any user-facing changes?   --------- Co-authored-by: B Vadlamani <[email protected]>

## Which issue does this PR close?  - Closes apache#22049 . ## Rationale for this change Root cause — datafusion/functions-window/src/ntile.rs:170-176 used the linear-interpolation formula i * n / num_rows to assign bucket numbers. That formula spreads the larger buckets evenly through the partition, but the SQL standard requires the first num_rows mod n buckets to be the larger ones. For NTILE(4) over 10 rows it produced bucket sizes 3,2,3,2 instead of 3,3,2,2 Fix — replaced the formula with the front-loaded distribution: compute base = num_rows / n and remainder = num_rows % n, treat the first remainder * (base+1) rows as the "large bucket" region (each bucket of size base+1), and the remainder as size-base buckets. The n > num_rows case (existing test NTILE(9223377) over 3 rows) still works because base = 0 forces every row into the "large" arm where each bucket holds one row.  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

## Which issue does this PR close? benchmarks for apache#21765. Also related to apache#21860 The goal is to merge this PR and then rebase the branch on apache#21765 to contain these benchmarks, so that they can be run and compared to the original.  ## Rationale for this change Originally this was included in apache#21765 but that PR is already very large. I decided to move it to its own separate PR  ## What changes are included in this PR? Adds benchmarks for the dictionary encoding array path of **new_group_values()**.  ## Are these changes tested? n/a  ## Are there any user-facing changes? no   --------- Co-authored-by: Kumar Ujjawal <[email protected]>

## Which issue does this PR close?  - Closes #. ## Rationale for this change  `EXPLAIN FORMAT TREE` is supported in logical plans, but protobuf serialization did not preserve the explain format. In Datafusion Ballista, we need the format field to generate corresponding distributed plan. apache/datafusion-ballista#1627 (comment) ## What changes are included in this PR?  - Add `ExplainFormat` to protobuf common definitions. - Add the `format` field to protobuf `ExplainNode`. - Regenerate protobuf code. ## Are these changes tested? Yes, we add a roundtrip test for `EXPLAIN FORMAT TREE`.  ## Are there any user-facing changes? No   --------- Co-authored-by: Kumar Ujjawal <[email protected]>

## Which issue does this PR close?  - Closes apache#18447. ## Rationale for this change The `array_replace` benchmark allocated ~90GB of memory before running (3 × 100M `Expr` literals), causing OOM on normal machines.  ## What changes are included in this PR? - Reduce `array_len` in `array_expression` bench from `100_000_000` to `100_000`. - Remove a broken `assert_eq!` (and its unused `expected_array`) that compared the `ScalarFunction` `Expr` returned by `array_replace_all` against the unmodified input — the two `Expr` trees are never equal. The OOM previously hid the failing assertion.  ## Are these changes tested? Yes, `cargo bench -p datafusion-functions-nested --bench array_expression` passes locally  ## Are there any user-facing changes? No

## Which issue does this PR close?  - Closes #. ## Rationale for this change  array_replace / array_replace_n / array_replace_all currently call `MutableArrayData::extend` once per non-matching element. This pr batches consecutive non-matching elements into a single extend call, reducing call count. ## What changes are included in this PR?  - Track contiguous non-matching runs and flush them as one extend call. - Add Criterion benchmark and SLT edge-case tests for n = 0 / -1 / > match_count. ### Benchmarks ``` group main perf ----- ---- ---- array_replace_all_int64/replace/list size: 10, num_rows: 4000 1.06 1149.7±23.40µs ? ?/sec 1.00 1080.3±71.22µs ? ?/sec array_replace_all_int64/replace/list size: 100, num_rows: 10000 1.70 11.2±0.19ms ? ?/sec 1.00 6.6±0.36ms ? ?/sec array_replace_all_int64/replace/list size: 500, num_rows: 10000 1.94 44.2±0.71ms ? ?/sec 1.00 22.8±0.48ms ? ?/sec array_replace_all_int64_nested/replace/list size: 10, num_rows: 4000 1.03 7.4±0.05ms ? ?/sec 1.00 7.2±0.26ms ? ?/sec array_replace_all_int64_nested/replace/list size: 100, num_rows: 3000 1.14 42.1±0.57ms ? ?/sec 1.00 36.9±0.22ms ? ?/sec array_replace_all_int64_nested/replace/list size: 300, num_rows: 1500 1.14 60.5±2.57ms ? ?/sec 1.00 52.8±0.60ms ? ?/sec array_replace_boolean/replace/list size: 10, num_rows: 4000 1.04 1087.5±25.31µs ? ?/sec 1.00 1042.4±18.85µs ? ?/sec array_replace_boolean/replace/list size: 100, num_rows: 10000 1.20 4.2±0.13ms ? ?/sec 1.00 3.5±0.06ms ? ?/sec array_replace_boolean/replace/list size: 500, num_rows: 10000 1.11 7.0±0.28ms ? ?/sec 1.00 6.3±0.06ms ? ?/sec array_replace_fixed_size_binary/replace/list size: 10, num_rows: 4000 1.03 1187.3±13.63µs ? ?/sec 1.00 1155.9±26.39µs ? ?/sec array_replace_fixed_size_binary/replace/list size: 100, num_rows: 10000 1.01 7.0±0.08ms ? ?/sec 1.00 6.9±0.67ms ? ?/sec array_replace_fixed_size_binary/replace/list size: 500, num_rows: 10000 1.00 23.6±0.61ms ? ?/sec 1.01 23.8±0.92ms ? ?/sec array_replace_int64/replace/list size: 10, num_rows: 4000 1.07 1071.8±25.30µs ? ?/sec 1.00 1003.3±24.68µs ? ?/sec array_replace_int64/replace/list size: 100, num_rows: 10000 1.16 4.0±0.07ms ? ?/sec 1.00 3.4±0.09ms ? ?/sec array_replace_int64/replace/list size: 500, num_rows: 10000 1.10 7.2±0.31ms ? ?/sec 1.00 6.6±0.34ms ? ?/sec array_replace_int64_nested/replace/list size: 10, num_rows: 4000 1.02 7.2±0.07ms ? ?/sec 1.00 7.0±0.21ms ? ?/sec array_replace_int64_nested/replace/list size: 100, num_rows: 3000 1.01 36.1±0.38ms ? ?/sec 1.00 35.8±1.62ms ? ?/sec array_replace_int64_nested/replace/list size: 300, num_rows: 1500 1.00 51.2±0.48ms ? ?/sec 1.00 51.1±0.67ms ? ?/sec array_replace_n_int64/replace/list size: 10, num_rows: 4000 1.09 1119.2±24.61µs ? ?/sec 1.00 1022.4±20.53µs ? ?/sec array_replace_n_int64/replace/list size: 100, num_rows: 10000 1.45 7.2±0.22ms ? ?/sec 1.00 5.0±0.16ms ? ?/sec array_replace_n_int64/replace/list size: 500, num_rows: 10000 1.68 25.3±0.38ms ? ?/sec 1.00 15.1±1.32ms ? ?/sec array_replace_n_int64_nested/replace/list size: 10, num_rows: 4000 1.03 7.4±0.08ms ? ?/sec 1.00 7.1±0.07ms ? ?/sec array_replace_n_int64_nested/replace/list size: 100, num_rows: 3000 1.05 38.5±0.36ms ? ?/sec 1.00 36.5±1.38ms ? ?/sec array_replace_n_int64_nested/replace/list size: 300, num_rows: 1500 1.04 55.0±0.41ms ? ?/sec 1.00 52.6±1.99ms ? ?/sec array_replace_strings/replace/list size: 10, num_rows: 4000 1.07 1443.5±18.35µs ? ?/sec 1.00 1348.6±41.07µs ? ?/sec array_replace_strings/replace/list size: 100, num_rows: 10000 1.09 10.9±0.17ms ? ?/sec 1.00 9.9±0.17ms ? ?/sec array_replace_strings/replace/list size: 500, num_rows: 10000 1.00 36.2±0.82ms ? ?/sec 1.04 37.5±0.91ms ? ?/sec ``` ## Are these changes tested? Yes — existing SLT tests and new edge-case coverage.  ## Are there any user-facing changes? No.

## Which issue does this PR close?  - Closes apache#22115. ## Rationale for this change Bug in `date_part` - `isodow` argument logic  ## What changes are included in this PR? - fix the logic - fix the docs  ## Are these changes tested? - Yes, unit tests  ## Are there any user-facing changes? - Yes, this PR fixes the logic bug. Docs are updated.

## Which issue does this PR close?  - Does not close an issue. - This is targeted toward high fanout repartitions we see in shuffles in distributed-datafusion (datafusion-contrib/datafusion-distributed#385, datafusion-contrib/datafusion-distributed#353). - Related ongoing effort to improve metrics and repartition performance: apache#21148, apache#22155. ## Rationale for this change  Hash repartition currently builds one output batch per non-empty target partition by calling `take_arrays` separately for each partition. At high fanout this means an input batch can issue many take kernels, which shows in repartition-heavy queries. This changes hash repartition to concatenate the per-partition row indices, call `take_arrays` once for the input batch, and then slice the reordered batch back into per-partition output batches. This is complementary to apache#22010: that PR reduces channel/gate traffic from many small batches, while this PR reduces the Arrow take-kernel work required to create the repartitioned batches. ## What changes are included in this PR?  - Replaces per-partition hash repartition `take_arrays` calls with one grouped `take_arrays` call per input batch. - Tracks partition ranges into the grouped reordered batch and returns zero-copy `RecordBatch::slice` outputs for each non-empty partition. How the grouped take works: ```text input rows: 0 1 2 3 4 5 6 partition 0: [2, 5] partition 1: [] partition 2: [0, 3, 4] partition 3: [1, 6] grouped indices: [2, 5, 0, 3, 4, 1, 6] partition ranges: [(0, start=0, len=2), (2, start=2, len=3), (3, start=5, len=2)] take once: rows [2, 5, 0, 3, 4, 1, 6] slice outputs: partition 0 = slice(0, 2) partition 2 = slice(2, 3) partition 3 = slice(5, 2) ``` ## Are these changes tested?  - `cargo test -p datafusion-physical-plan repartition --lib` **Benchmarks:** Default TPCH SF10 summary, with no `--batch-size` override: | Partitions | main total ms | grouped total ms | change | wins | losses | biggest win | biggest loss |---:|---:|---:|---:|---:|---:|---:|---:| | 8 | 6234.28 | 6149.98 | -1.35% | 10 | 12 | Q3 -22.12% | Q21 5.47% | | 16 | 5602.63 | 5427.40 | -3.13% | 18 | 4 | Q21 -10.67% | Q10 4.47% | | 32 | 6097.10 | 5738.12 | -5.89% | 20 | 2 | Q8 -10.45% | Q6 0.47% | | 64 | 7194.70 | 6693.30 | -6.97% | 15 | 7 | Q21 -15.92% | Q1 5.02% | | 300 | 26276.60 | 23701.32 | -9.80% | 19 | 3 | Q21 -24.24% | Q1 9.45% | <details> <summary>TPCH SF10 default batch size, 8 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 411.40 | 356.46 | -13.35% | 1.154x | | Q2 | 117.97 | 95.68 | -18.89% | 1.233x | | Q3 | 278.88 | 217.20 | -22.12% | 1.284x | | Q4 | 104.92 | 98.47 | -6.15% | 1.065x | | Q5 | 311.36 | 302.12 | -2.97% | 1.031x | | Q6 | 133.82 | 135.13 | 0.98% | 0.990x | | Q7 | 366.32 | 360.50 | -1.59% | 1.016x | | Q8 | 408.86 | 391.14 | -4.33% | 1.045x | | Q9 | 509.62 | 515.74 | 1.20% | 0.988x | | Q10 | 278.97 | 273.80 | -1.85% | 1.019x | | Q11 | 76.55 | 75.34 | -1.58% | 1.016x | | Q12 | 175.56 | 180.87 | 3.03% | 0.971x | | Q13 | 211.03 | 221.03 | 4.74% | 0.955x | | Q14 | 183.05 | 189.95 | 3.77% | 0.964x | | Q15 | 318.46 | 328.85 | 3.26% | 0.968x | | Q16 | 57.66 | 57.70 | 0.08% | 0.999x | | Q17 | 505.05 | 503.77 | -0.25% | 1.003x | | Q18 | 596.49 | 602.77 | 1.05% | 0.990x | | Q19 | 273.60 | 283.41 | 3.58% | 0.965x | | Q20 | 255.73 | 267.30 | 4.52% | 0.957x | | Q21 | 592.44 | 624.83 | 5.47% | 0.948x | | Q22 | 66.54 | 67.91 | 2.05% | 0.980x | </details> <details> <summary>TPCH SF10 default batch size, 16 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 278.95 | 276.85 | -0.76% | 1.008x | | Q2 | 95.84 | 94.86 | -1.02% | 1.010x | | Q3 | 205.24 | 195.05 | -4.97% | 1.052x | | Q4 | 93.60 | 90.58 | -3.23% | 1.033x | | Q5 | 292.34 | 289.93 | -0.82% | 1.008x | | Q6 | 103.59 | 106.02 | 2.35% | 0.977x | | Q7 | 370.86 | 365.40 | -1.47% | 1.015x | | Q8 | 392.01 | 364.63 | -6.98% | 1.075x | | Q9 | 512.66 | 483.45 | -5.70% | 1.060x | | Q10 | 246.01 | 257.01 | 4.47% | 0.957x | | Q11 | 73.33 | 70.21 | -4.26% | 1.045x | | Q12 | 143.58 | 143.53 | -0.04% | 1.000x | | Q13 | 193.30 | 193.57 | 0.14% | 0.999x | | Q14 | 157.01 | 146.14 | -6.92% | 1.074x | | Q15 | 255.58 | 258.73 | 1.23% | 0.988x | | Q16 | 58.90 | 57.14 | -2.97% | 1.031x | | Q17 | 515.22 | 491.16 | -4.67% | 1.049x | | Q18 | 518.50 | 516.90 | -0.31% | 1.003x | | Q19 | 212.28 | 211.63 | -0.30% | 1.003x | | Q20 | 229.34 | 224.54 | -2.09% | 1.021x | | Q21 | 594.29 | 530.87 | -10.67% | 1.119x | | Q22 | 60.20 | 59.18 | -1.70% | 1.017x | </details> <details> <summary>TPCH SF10 default batch size, 32 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 294.06 | 286.80 | -2.47% | 1.025x | | Q2 | 110.59 | 103.55 | -6.37% | 1.068x | | Q3 | 227.86 | 215.08 | -5.61% | 1.059x | | Q4 | 110.99 | 102.77 | -7.41% | 1.080x | | Q5 | 347.34 | 319.49 | -8.02% | 1.087x | | Q6 | 109.39 | 109.91 | 0.47% | 0.995x | | Q7 | 423.98 | 385.42 | -9.09% | 1.100x | | Q8 | 428.83 | 384.00 | -10.45% | 1.117x | | Q9 | 559.81 | 510.72 | -8.77% | 1.096x | | Q10 | 269.17 | 265.02 | -1.54% | 1.016x | | Q11 | 85.99 | 80.21 | -6.72% | 1.072x | | Q12 | 153.67 | 150.36 | -2.15% | 1.022x | | Q13 | 197.90 | 188.72 | -4.64% | 1.049x | | Q14 | 161.28 | 153.93 | -4.55% | 1.048x | | Q15 | 259.92 | 261.01 | 0.42% | 0.996x | | Q16 | 64.90 | 63.70 | -1.85% | 1.019x | | Q17 | 574.18 | 531.76 | -7.39% | 1.080x | | Q18 | 572.23 | 538.68 | -5.86% | 1.062x | | Q19 | 227.95 | 220.19 | -3.41% | 1.035x | | Q20 | 232.25 | 225.80 | -2.78% | 1.029x | | Q21 | 622.54 | 579.94 | -6.84% | 1.073x | | Q22 | 62.29 | 61.06 | -1.98% | 1.020x | </details> <details> <summary>TPCH SF10 default batch size, 64 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 285.10 | 299.41 | 5.02% | 0.952x | | Q2 | 161.42 | 153.51 | -4.90% | 1.052x | | Q3 | 297.85 | 272.09 | -8.65% | 1.095x | | Q4 | 147.28 | 140.69 | -4.47% | 1.047x | | Q5 | 428.29 | 381.28 | -10.98% | 1.123x | | Q6 | 106.27 | 108.41 | 2.02% | 0.980x | | Q7 | 494.50 | 443.89 | -10.23% | 1.114x | | Q8 | 507.01 | 446.69 | -11.90% | 1.135x | | Q9 | 667.11 | 624.78 | -6.34% | 1.068x | | Q10 | 294.91 | 299.05 | 1.40% | 0.986x | | Q11 | 112.17 | 104.79 | -6.57% | 1.070x | | Q12 | 168.23 | 166.87 | -0.81% | 1.008x | | Q13 | 198.74 | 196.30 | -1.23% | 1.012x | | Q14 | 175.31 | 177.74 | 1.39% | 0.986x | | Q15 | 265.68 | 265.71 | 0.01% | 1.000x | | Q16 | 85.69 | 82.93 | -3.22% | 1.033x | | Q17 | 691.32 | 629.09 | -9.00% | 1.099x | | Q18 | 697.85 | 617.88 | -11.46% | 1.129x | | Q19 | 237.00 | 243.78 | 2.86% | 0.972x | | Q20 | 272.55 | 278.57 | 2.21% | 0.978x | | Q21 | 813.29 | 683.82 | -15.92% | 1.189x | | Q22 | 87.14 | 76.04 | -12.73% | 1.146x | </details> <details> <summary>TPCH SF10 default batch size, 300 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 277.84 | 304.08 | 9.45% | 0.914x | | Q2 | 1303.10 | 1268.65 | -2.64% | 1.027x | | Q3 | 1496.14 | 1393.15 | -6.88% | 1.074x | | Q4 | 681.20 | 652.85 | -4.16% | 1.043x | | Q5 | 1680.43 | 1469.91 | -12.53% | 1.143x | | Q6 | 100.65 | 105.75 | 5.07% | 0.952x | | Q7 | 1880.26 | 1652.83 | -12.10% | 1.138x | | Q8 | 1956.81 | 1760.72 | -10.02% | 1.111x | | Q9 | 1787.75 | 1454.84 | -18.62% | 1.229x | | Q10 | 1334.62 | 1296.02 | -2.89% | 1.030x | | Q11 | 1018.99 | 994.13 | -2.44% | 1.025x | | Q12 | 768.97 | 780.88 | 1.55% | 0.985x | | Q13 | 671.88 | 638.51 | -4.97% | 1.052x | | Q14 | 603.10 | 586.19 | -2.80% | 1.029x | | Q15 | 302.19 | 295.28 | -2.29% | 1.023x | | Q16 | 597.64 | 585.39 | -2.05% | 1.021x | | Q17 | 1963.57 | 1712.46 | -12.79% | 1.147x | | Q18 | 1942.46 | 1634.96 | -15.83% | 1.188x | | Q19 | 818.85 | 808.19 | -1.30% | 1.013x | | Q20 | 1499.39 | 1468.55 | -2.06% | 1.021x | | Q21 | 3006.35 | 2277.49 | -24.24% | 1.320x | | Q22 | 584.39 | 560.47 | -4.09% | 1.043x | </details> **Stress cases:** - These runs use `--batch-size 1024` to stress the repartition path. They are included to show the mechanism under smaller input batches and higher output fanout, not as the primary end-to-end performance claim. <details> <summary>TPCH SF10, 8 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 640.78 | 451.82 | -29.49% | 1.420x | | Q2 | 315.81 | 150.07 | -52.48% | 2.100x | | Q3 | 899.21 | 375.88 | -58.20% | 2.390x | | Q4 | 469.31 | 217.07 | -53.75% | 2.160x | | Q5 | 1131.37 | 446.36 | -60.55% | 2.530x | | Q6 | 376.40 | 163.66 | -56.52% | 2.300x | | Q7 | 1388.40 | 484.36 | -65.11% | 2.870x | | Q8 | 1369.67 | 571.62 | -58.27% | 2.400x | | Q9 | 1834.81 | 739.88 | -59.68% | 2.480x | | Q10 | 813.73 | 361.94 | -55.52% | 2.250x | | Q11 | 267.06 | 114.84 | -57.00% | 2.330x | | Q12 | 526.41 | 250.39 | -52.43% | 2.100x | | Q13 | 760.54 | 324.78 | -57.30% | 2.340x | | Q14 | 446.91 | 221.04 | -50.54% | 2.020x | | Q15 | 764.64 | 375.67 | -50.87% | 2.040x | | Q16 | 167.74 | 80.36 | -52.09% | 2.090x | | Q17 | 1801.72 | 763.58 | -57.62% | 2.360x | | Q18 | 3303.89 | 1649.87 | -50.06% | 2.000x | | Q19 | 694.16 | 354.97 | -48.86% | 1.960x | | Q20 | 693.91 | 323.17 | -53.43% | 2.150x | | Q21 | 3112.83 | 1065.36 | -65.78% | 2.920x | | Q22 | 205.88 | 95.97 | -53.38% | 2.150x | </details> <details> <summary>TPCH SF10, 16 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 518.84 | 328.66 | -36.66% | 1.580x | | Q2 | 350.47 | 148.64 | -57.59% | 2.360x | | Q3 | 1003.55 | 371.04 | -63.03% | 2.700x | | Q4 | 589.70 | 258.05 | -56.24% | 2.290x | | Q5 | 1343.64 | 506.01 | -62.34% | 2.660x | | Q6 | 322.21 | 130.93 | -59.37% | 2.460x | | Q7 | 1527.85 | 550.88 | -63.94% | 2.770x | | Q8 | 1476.46 | 578.77 | -60.80% | 2.550x | | Q9 | 2091.16 | 785.54 | -62.44% | 2.660x | | Q10 | 817.98 | 331.02 | -59.53% | 2.470x | | Q11 | 341.46 | 123.31 | -63.89% | 2.770x | | Q12 | 493.51 | 221.61 | -55.10% | 2.230x | | Q13 | 690.52 | 290.54 | -57.92% | 2.380x | | Q14 | 410.54 | 171.45 | -58.24% | 2.390x | | Q15 | 733.96 | 290.56 | -60.41% | 2.530x | | Q16 | 197.35 | 86.09 | -56.37% | 2.290x | | Q17 | 2089.12 | 828.96 | -60.32% | 2.520x | | Q18 | 2712.00 | 1097.77 | -59.52% | 2.470x | | Q19 | 602.77 | 260.74 | -56.74% | 2.310x | | Q20 | 661.20 | 288.58 | -56.35% | 2.290x | | Q21 | 5490.50 | 1151.50 | -79.03% | 4.770x | | Q22 | 198.38 | 103.13 | -48.01% | 1.920x | </details> <details> <summary>TPCH SF10, 32 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 533.86 | 338.54 | -36.59% | 1.580x | | Q2 | 439.59 | 199.50 | -54.62% | 2.200x | | Q3 | 1242.19 | 510.11 | -58.93% | 2.440x | | Q4 | 743.92 | 363.33 | -51.16% | 2.050x | | Q5 | 1711.97 | 666.50 | -61.07% | 2.570x | | Q6 | 325.39 | 134.07 | -58.80% | 2.430x | | Q7 | 1947.59 | 722.22 | -62.92% | 2.700x | | Q8 | 1914.31 | 775.62 | -59.48% | 2.470x | | Q9 | 2662.07 | 976.47 | -63.32% | 2.730x | | Q10 | 902.80 | 362.71 | -59.82% | 2.490x | | Q11 | 400.93 | 170.81 | -57.40% | 2.350x | | Q12 | 572.19 | 265.06 | -53.68% | 2.160x | | Q13 | 736.31 | 296.82 | -59.69% | 2.480x | | Q14 | 430.11 | 180.93 | -57.93% | 2.380x | | Q15 | 732.36 | 327.12 | -55.33% | 2.240x | | Q16 | 245.97 | 116.24 | -52.74% | 2.120x | | Q17 | 2711.18 | 1100.17 | -59.42% | 2.460x | | Q18 | 2946.70 | 1176.02 | -60.09% | 2.510x | | Q19 | 600.47 | 258.58 | -56.94% | 2.320x | | Q20 | 765.20 | 337.01 | -55.96% | 2.270x | | Q21 | 10062.70 | 1534.95 | -84.75% | 6.560x | | Q22 | 250.50 | 128.27 | -48.79% | 1.950x | </details> <details> <summary>TPCH SF10, 64 partitions, all queries</summary> | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q1 | 595.70 | 324.74 | -45.49% | 1.830x | | Q2 | 663.08 | 305.30 | -53.96% | 2.170x | | Q3 | 1744.90 | 727.81 | -58.29% | 2.400x | | Q4 | 1070.72 | 566.20 | -47.12% | 1.890x | | Q5 | 2447.07 | 938.91 | -61.63% | 2.610x | | Q6 | 315.47 | 132.73 | -57.93% | 2.380x | | Q7 | 2807.33 | 1004.83 | -64.21% | 2.790x | | Q8 | 2674.51 | 1069.64 | -60.01% | 2.500x | | Q9 | 3777.94 | 1424.08 | -62.31% | 2.650x | | Q10 | 1086.91 | 469.38 | -56.82% | 2.320x | | Q11 | 575.59 | 264.02 | -54.13% | 2.180x | | Q12 | 841.83 | 387.25 | -54.00% | 2.170x | | Q13 | 867.57 | 379.90 | -56.21% | 2.280x | | Q14 | 470.87 | 214.58 | -54.43% | 2.190x | | Q15 | 762.07 | 340.55 | -55.31% | 2.240x | | Q16 | 337.20 | 179.25 | -46.84% | 1.880x | | Q17 | 3953.82 | 1701.46 | -56.97% | 2.320x | | Q18 | 3763.51 | 1606.90 | -57.30% | 2.340x | | Q19 | 644.43 | 314.27 | -51.23% | 2.050x | | Q20 | 973.56 | 453.24 | -53.45% | 2.150x | | Q21 | 19356.91 | 2396.96 | -87.62% | 8.080x | | Q22 | 366.20 | 195.40 | -46.64% | 1.870x | </details> <details> <summary>TPCH SF10, 300 partitions, targeted high-fanout queries</summary> Yes this is a real use case for fanout in distributed-datafusion | Query | main ms | grouped ms | change | speedup | |---:|---:|---:|---:|---:| | Q3 | 2543.94 | 2250.91 | -11.52% | 1.130x | | Q9 | 6495.22 | 4755.78 | -26.78% | 1.370x | | Q10 | 1869.05 | 1709.18 | -8.55% | 1.090x | | Q13 | 1238.63 | 1157.47 | -6.55% | 1.070x | | Q15 | 461.51 | 446.25 | -3.31% | 1.030x | | Q21 | 37810.29 | 5594.01 | -85.21% | 6.760x | | Q22 | 1084.95 | 1058.74 | -2.42% | 1.020x | </details> <details> <summary>TPCH SF10, 300 partitions, peak RSS stress</summary> Measured with `/usr/bin/time -l`, one iteration, `--batch-size 1024`, `--partitions 300`, and no DataFusion memory limit. RSS is process peak resident set size from the OS. | Query | main ms | grouped ms | time change | main peak RSS | grouped peak RSS | RSS change | |---:|---:|---:|---:|---:|---:|---:| | Q7 | 5171.45 | 4151.15 | -19.73% | 3.69 GiB | 3.75 GiB | 1.61% | | Q9 | 6055.57 | 4758.10 | -21.43% | 4.01 GiB | 4.01 GiB | 0.04% | | Q21 | 36300.80 | 5810.14 | -83.99% | 2.96 GiB | 2.05 GiB | -30.79% | </details> #### Memory concern and follow-up work This PR changes output batches from materializing per-partition batches to slices of one reordered batch. This means sibling slices can share the same buffers. Potential concern: ```text one reordered batch allocation -> slice for partition 0 -> slice for partition 1 -> slice for partition 2 ``` A slow output partition can keep the shared reordered batch buffers alive until its slice is dropped. Also, `RecordBatch::get_array_memory_size()` may count shared slice buffers repeatedly when repartition reserves memory per output batch. The peak RSS stress above did not show a process-memory regression in the measured queries. Follow-up work should add buffer-aware accounting. ## Are there any user-facing changes?  No.

## Which issue does this PR close?  - Closes apache#19685. ## Rationale for this change Physical explain output only showed the alias for aliased aggregates. That made it hard to understand the plan, especially when the aggregate had a filter, explicit RESPECT NULLS, or a custom UDAF display.  ## What changes are included in this PR? - Show the full aggregate expression in physical explain for user-written aggregate aliases. - Keep internal aliases like count(*) compact in physical explain. - Replace the old hidden metadata approach with an explicit is_internal flag on Alias. - Preserve that flag through planner rewrites, tree rewrites, and proto round-trip. - Add tests for aliased aggregate explain output, including: - normal aliased aggregates - quoted aliases - explicit RESPECT NULLS - custom human display - count(*) - nested internal alias display - Add an upgrade note for the public Alias API change.  ## Are these changes tested? Yes  ## Are there any user-facing changes? Yes. - Physical explain output is clearer for aliased aggregate expressions. - Alias now has a new is_internal field. This is a public API change for users who build or pattern match Alias directly. The upgrade guide has been updated with the needed changes.

…des (apache#22011) ## Which issue does this PR close?  - Closes apache#20418 (Looks like this was accidentally closed early) - Informs: apache#21207 (comment) ## Rationale for this change `SortExec`, `AggregateExec`, and `HashJoinExec` do not serialize their dynamic filters, so plans lose dynamic filtering when they are serialized and sent across network boundaries. ## What changes are included in this PR? This change adds `with_dynamic_filter_expr()` and `dynamic_filter_expr()` to `SortExec`, `AggregateExec`, and `HashJoinExec`. ``` pub fn with_dynamic_filter_expr( mut self, filter: Arc<DynamicFilterPhysicalExpr>, ) -> Result<Self> pub fn dynamic_filter_expr(&self) -> Option<&Arc<DynamicFilterPhysicalExpr>> { ``` This are used as getters and setters for the `proto` crate to get and set dynamic filters. ## Are these changes tested? Yes. See `datafusion/datafusion/proto/tests/cases/roundtrip_physical_plan.rs`. There are also tests for the plan nodes in the `physical-plan` crate. ## Are there any user-facing changes? `SortExec`, `AggregateExec`, and `HashJoinExec` now roundtrip serialize dynamic filter expressions. --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

## Which issue does this PR close?  - Closes #. ## Rationale for this change  ## What changes are included in this PR?  Eliminates `SortExec` on `generate_series()` by exposing the existing sort order property in the data source `ExecutionPlan`, the existing optimizer heuristics will remove it automatically. Demo in `datafusion-cli`: ### main ``` DataFusion CLI v53.1.0 > explain select * from generate_series(1,100) as t1(v1) order by v1; +---------------+-------------------------------+ | plan_type | plan | +---------------+-------------------------------+ | physical_plan | ┌───────────────────────────┐ | | | │ SortExec │ | | | │ -------------------- │ | | | │ v1@0 ASC NULLS LAST │ | | | └─────────────┬─────────────┘ | | | ┌─────────────┴─────────────┐ | | | │ ProjectionExec │ | | | │ -------------------- │ | | | │ v1: value │ | | | └─────────────┬─────────────┘ | | | ┌─────────────┴─────────────┐ | | | │ LazyMemoryExec │ | | | │ -------------------- │ | | | │ batch_generators: │ | | | │ generate_series: start=1, │ | | | │ end=100, batch_size=8192 │ | | | └───────────────────────────┘ | | | | +---------------+-------------------------------+ 1 row(s) fetched. Elapsed 0.006 seconds. ``` ### PR ``` DataFusion CLI v53.1.0 > explain select * from generate_series(1,100) as t1(v1) order by v1; +---------------+-------------------------------+ | plan_type | plan | +---------------+-------------------------------+ | physical_plan | ┌───────────────────────────┐ | | | │ ProjectionExec │ | | | │ -------------------- │ | | | │ v1: value │ | | | └─────────────┬─────────────┘ | | | ┌─────────────┴─────────────┐ | | | │ LazyMemoryExec │ | | | │ -------------------- │ | | | │ batch_generators: │ | | | │ generate_series: start=1, │ | | | │ end=100, batch_size=8192 │ | | | └───────────────────────────┘ | | | | +---------------+-------------------------------+ ``` ## Are these changes tested?  slt ## Are there any user-facing changes?

…rtitionExec (apache#22010) ## Which issue does this PR close?  - Closes apache#22202 ## Rationale for this change  Today RepartitionExec emits one small batch per (input batch × non-empty output partition), then coalesces those small batches back into target-sized ones on the consumer side. That means the channel layer (memory accounting, gate, await suspensions) does work proportional to num_partitions per input batch, even though each small batch only carries batch_size / num_partitions rows. Moving the coalescing producer-side, before the gate, collapses the channel traffic and reduces sensitivity to high output fanout. This gets much worst in https://github.com/datafusion-contrib/datafusion-distributed, which uses `RepartitionExec` as the foundational backbone for network shuffles: it scales up the `RepartitionExec` output partitions to match P (partitions) * W (workers), where P is typically in the range of 12-24, and W can be from 1 to thousands. The fanout overhead that the current `RepartitionExec` introduces is pretty big in that setup. Ideally, the overhead of fanning many small `RecordBatches` should be as small as possible. ## What changes are included in this PR?  - A producer-side coalescer per output partition, shared across input tasks, that runs before the channel's gate. - The redundant consumer-side coalescer in PerPartitionStream is removed. - BatchPartitioner is unchanged — only the layer between the partitioner and the channel. ## Are these changes tested?  Yes, by existing tests ## Are there any user-facing changes? No

## Which issue does this PR close?  - N/A, simple doc typos I discovered. These changes should make the `PushDownFilter` optimizer rule documentation a little clearer. ## Rationale for this change  ## What changes are included in this PR?  ## Are these changes tested?  ## Are there any user-facing changes?

…d SELECT INTO (apache#22290) ## Which issue does this PR close?  - Closes apache#22167 ## Rationale for this change `CREATE TABLE AS`, `CREATE VIEW`, and `SELECT INTO` can persist only plain column names. Before this change, a query like a self join could produce qualified output columns such as `x.column1` and `y.column1`, which are valid while planning. But when the table or view was created, those qualifiers were dropped and the stored schema became `column1`, `column1`, ... with duplicates. That meant the create step succeeded, but the created table or view failed later when the user tried to read from it. The object existed in the catalog but was not usable. This PR fixes that by rejecting these cases during execution of the DDL operators, before the table or view is registered.  ## What changes are included in this PR? This PR adds an execution-side check that validates the final output schema has unique unqualified column names. It applies that check in: - `create_memory_table` - `create_view` This covers: - `CREATE TABLE AS` - `CREATE VIEW` - `SELECT INTO` The check runs after optimization or type coercion and before registration, so it validates the actual names that would be stored. For `IF NOT EXISTS`, execution keeps the existing no-op behavior when the target already exists, so validation only runs when a new object would actually be created or replaced. This PR also adds: - sqllogictest coverage for the duplicate-column self-join case for all three flows - direct execution-level regression tests for create / replace table and view paths  ## Are these changes tested? Yes  ## Are there any user-facing changes? Invalid `CREATE TABLE AS`, `CREATE VIEW`, and `SELECT INTO` statements that would create an object with duplicate unqualified column names now fail early during DDL execution with a schema error, instead of succeeding and creating an unreadable table or view. No API Changes

…pache#22375) ## Which issue does this PR close?  - Closes apache#22374. ## Rationale for this change See apache#22374.  ## What changes are included in this PR?  This change includes a fix for the issue and a test that fails without this fix. The fix is straightforward: when splitting on the wildcard, we also unescape any escape sequences in the prefix. ## Are these changes tested?  I added a test that fails without this fix. ## Are there any user-facing changes? No

…#21643) ## Which issue does this PR close?  - Closes apache#21642. - Relevant PR to datafusion-testing: apache/datafusion-testing#20 ## Rationale for this change  It just makes more sense - if the user knows that they want a particular filter before the others, let them do that. Also, the existing comments indicate that this was the original intention. ## What changes are included in this PR?  The combined predicate of multiple filter plan nodes now preserves execution order. ## Are these changes tested?  Yes, added unit tests. ## Are there any user-facing changes?   Yes, execution order of predicates might change.

alamb and others added 2 commits April 20, 2026 13:50

pull Bot locked and limited conversation to collaborators Apr 20, 2026

pull Bot added the ⤵️ pull label Apr 20, 2026

pull Bot merged commit a311d14 into buraksenn:main Apr 20, 2026
15 of 16 checks passed

Navigation Menu

Repository navigation

[pull] main from apache:main - #123

[pull] main from apache:main#123
pull[bot] merged 2 commits into
buraksenn:mainfrom
apache:main

pull Bot commented Apr 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

pull Bot commented Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pull Bot commented Apr 20, 2026 •

edited

Loading