Feat: Revive to use upstream arrow coalesce by zhuqi-lucas · Pull Request #17105 · apache/datafusion

zhuqi-lucas · 2025-08-09T02:43:54Z

Which issue does this PR close?

Revive Draft: Use upstream arrow coalesce kernel in DataFusion #16249
Related to Optimize take/filter/concat from multiple input arrays to a single large output array arrow-rs#6692
Related to Enable parquet filter pushdown (filter_pushdown) by default #3463

Rationale for this change

Revive Draft: Use upstream arrow coalesce kernel in DataFusion #16249

And fix conflicts

Related to Optimize take/filter/concat from multiple input arrays to a single large output array arrow-rs#6692
Related to Enable parquet filter pushdown (filter_pushdown) by default #3463

What changes are included in this PR?

This PR refactors the BatchCoalescer in DataFusion to use the proposed upstream API to show that it

Can be used (api is complete enough)
Is not any slower

Are these changes tested?

Yes

Are there any user-facing changes?

No

…oalesce

…eam_arrow_coalesce

alamb · 2025-08-11T11:49:31Z

🤖 ./gh_compare_branch.shBenchmark Script Running
Linux aal-dev 6.11.0-1016-gcp #16~24.04.1-Ubuntu SMP Wed May 28 02:40:52 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing revive_to_use_upstream_arrow_coalesce (8bbadaf) to ab794d2diff using: tpch_mem
Results will be posted here when complete

alamb · 2025-08-11T12:16:09Z

🤖: Benchmark completed

Details

Comparing HEAD and revive_to_use_upstream_arrow_coalesce
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ revive_to_use_upstream_arrow_coalesce ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ QQuery 1 │ 95.61 ms │ 92.56 ms │ no change │
│ QQuery 2 │ 20.85 ms │ 22.44 ms │ 1.08x slower │
│ QQuery 3 │ 31.93 ms │ 36.28 ms │ 1.14x slower │
│ QQuery 4 │ 18.15 ms │ 19.48 ms │ 1.07x slower │
│ QQuery 5 │ 48.85 ms │ 53.88 ms │ 1.10x slower │
│ QQuery 6 │ 12.03 ms │ 11.62 ms │ no change │
│ QQuery 7 │ 88.27 ms │ 93.17 ms │ 1.06x slower │
│ QQuery 8 │ 24.33 ms │ 24.10 ms │ no change │
│ QQuery 9 │ 53.84 ms │ 55.02 ms │ no change │
│ QQuery 10 │ 40.33 ms │ 41.29 ms │ no change │
│ QQuery 11 │ 11.20 ms │ 11.65 ms │ no change │
│ QQuery 12 │ 29.78 ms │ 29.46 ms │ no change │
│ QQuery 13 │ 25.89 ms │ 26.05 ms │ no change │
│ QQuery 14 │ 9.66 ms │ 10.02 ms │ no change │
│ QQuery 15 │ 19.14 ms │ 18.82 ms │ no change │
│ QQuery 16 │ 17.42 ms │ 17.74 ms │ no change │
│ QQuery 17 │ 96.53 ms │ 95.86 ms │ no change │
│ QQuery 18 │ 179.04 ms │ 179.63 ms │ no change │
│ QQuery 19 │ 24.01 ms │ 26.11 ms │ 1.09x slower │
│ QQuery 20 │ 31.57 ms │ 33.97 ms │ 1.08x slower │
│ QQuery 21 │ 139.56 ms │ 151.41 ms │ 1.08x slower │
│ QQuery 22 │ 13.78 ms │ 14.77 ms │ 1.07x slower │
└──────────────┴───────────┴───────────────────────────────────────┴──────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1031.76ms │
│ Total Time (revive_to_use_upstream_arrow_coalesce) │ 1065.32ms │
│ Average Time (HEAD) │ 46.90ms │
│ Average Time (revive_to_use_upstream_arrow_coalesce) │ 48.42ms │
│ Queries Faster │ 0 │
│ Queries Slower │ 9 │
│ Queries with No Change │ 13 │
│ Queries with Failure │ 0 │
└──────────────────────────────────────────────────────┴───────────┘

alamb · 2025-08-11T12:20:55Z

🤔 the new kernel seems to slow down. I wonder if the overhead of precisely sized output batches is causing the issue

zhuqi-lucas · 2025-08-11T12:33:08Z

🤔 the new kernel seems to slow down. I wonder if the overhead of precisely sized output batches is causing the issue

Good point @alamb , i agree this is the only difference. I can add a test PR to make upstream do not generate precisely sized output batches, but when we ensure capacity for the increment buffer size, it seems we need to make the size change since we do not keep the same target size for this change.

The latest benchmark seems a little better.

🤖: Benchmark completed

Details

Comparing HEAD and revive_to_use_upstream_arrow_coalesce
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ revive_to_use_upstream_arrow_coalesce ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ QQuery 1 │ 95.61 ms │ 92.56 ms │ no change │
│ QQuery 2 │ 20.85 ms │ 22.44 ms │ 1.08x slower │
│ QQuery 3 │ 31.93 ms │ 36.28 ms │ 1.14x slower │
│ QQuery 4 │ 18.15 ms │ 19.48 ms │ 1.07x slower │
│ QQuery 5 │ 48.85 ms │ 53.88 ms │ 1.10x slower │
│ QQuery 6 │ 12.03 ms │ 11.62 ms │ no change │
│ QQuery 7 │ 88.27 ms │ 93.17 ms │ 1.06x slower │
│ QQuery 8 │ 24.33 ms │ 24.10 ms │ no change │
│ QQuery 9 │ 53.84 ms │ 55.02 ms │ no change │
│ QQuery 10 │ 40.33 ms │ 41.29 ms │ no change │
│ QQuery 11 │ 11.20 ms │ 11.65 ms │ no change │
│ QQuery 12 │ 29.78 ms │ 29.46 ms │ no change │
│ QQuery 13 │ 25.89 ms │ 26.05 ms │ no change │
│ QQuery 14 │ 9.66 ms │ 10.02 ms │ no change │
│ QQuery 15 │ 19.14 ms │ 18.82 ms │ no change │
│ QQuery 16 │ 17.42 ms │ 17.74 ms │ no change │
│ QQuery 17 │ 96.53 ms │ 95.86 ms │ no change │
│ QQuery 18 │ 179.04 ms │ 179.63 ms │ no change │
│ QQuery 19 │ 24.01 ms │ 26.11 ms │ 1.09x slower │
│ QQuery 20 │ 31.57 ms │ 33.97 ms │ 1.08x slower │
│ QQuery 21 │ 139.56 ms │ 151.41 ms │ 1.08x slower │
│ QQuery 22 │ 13.78 ms │ 14.77 ms │ 1.07x slower │
└──────────────┴───────────┴───────────────────────────────────────┴──────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1031.76ms │
│ Total Time (revive_to_use_upstream_arrow_coalesce) │ 1065.32ms │
│ Average Time (HEAD) │ 46.90ms │
│ Average Time (revive_to_use_upstream_arrow_coalesce) │ 48.42ms │
│ Queries Faster │ 0 │
│ Queries Slower │ 9 │
│ Queries with No Change │ 13 │
│ Queries with Failure │ 0 │
└──────────────────────────────────────────────────────┴───────────┘

alamb · 2025-08-11T13:29:59Z

🤔 the new kernel seems to slow down. I wonder if the overhead of precisely sized output batches is causing the issue
Good point @alamb , i agree this is the only difference. I can add a test PR to make upstream do not generate precisely sized output batches, but when we ensure capacity for the increment buffer size, it seems we need to make the size change since we do not keep the same target size for this change.
The latest benchmark seems a little better.

Thanks @zhuqi-lucas -- what I was thinking about was something like the following

let target_batch_size = 4;letmut coalescer = BatchCoalescer::new(batch1.schema(),4).with_exact_size(false)

Before we spend a lot of time polishing / testing a PR for that it would probably be good to hack up a POC and verify it actually improves performance

Thank you for your willingness to help along with this project. It is something I have thought was important (but not critical) for a long time and so having someone to help really makes a big difference

zhuqi-lucas · 2025-08-11T13:43:51Z

🤔 the new kernel seems to slow down. I wonder if the overhead of precisely sized output batches is causing the issue
Good point @alamb , i agree this is the only difference. I can add a test PR to make upstream do not generate precisely sized output batches, but when we ensure capacity for the increment buffer size, it seems we need to make the size change since we do not keep the same target size for this change.
The latest benchmark seems a little better.
Thanks @zhuqi-lucas -- what I was thinking about was something like the following
let target_batch_size = 4;letmut coalescer = BatchCoalescer::new(batch1.schema(),4).with_exact_size(false)
Before we spend a lot of time polishing / testing a PR for that it would probably be good to hack up a POC and verify it actually improves performance
Thank you for your willingness to help along with this project. It is something I have thought was important (but not critical) for a long time and so having someone to help really makes a big difference

Thank you @alamb for good suggestion! It looks pretty cool to me, and a config for this is very clever idea.

let target_batch_size = 4;letmut coalescer = BatchCoalescer::new(batch1.schema(),4).with_exact_size(false)

I will try to address this for upstream first, so we can easily testing it for datafusion.

zhuqi-lucas · 2025-08-12T05:18:37Z

Updated @alamb , i created the PR for non-exact size now:

#17136

still working on performance

2010YOUY01 · 2025-08-13T08:18:38Z

For the tpch_mem slowdown, another possible reason could be unnecessary copies for batches that are exactly batch_size.

For certain operators, there might already be an internal mechanism to ensure their output is exactly batch_size. From a quick look at the implementation, the old version could pass such batches through directly, whereas this PR forces them to be copied.

Another potential improvement: could we make this pass-through threshold more lenient? For example, if the coalescer receives a batch with size >= batch_size / 2, it could pass it through without coalescing. In such cases, the output size is already large enough to benefit from vectorization, so the extra concatenation might not add much value.

zhuqi-lucas · 2025-08-13T08:36:03Z

For the tpch_mem slowdown, another possible reason could be unnecessary copies for batches that are exactly batch_size.
For certain operators, there might already be an internal mechanism to ensure their output is exactly batch_size. From a quick look at the implementation, the old version could pass such batches through directly, whereas this PR forces them to be copied.
Another potential improvement: could we make this pass-through threshold more lenient? For example, if the coalescer receives a batch with size >= batch_size / 2, it could pass it through without coalescing. In such cases, the output size is already large enough to benefit from vectorization, so the extra concatenation might not add much value.

Thank you @2010YOUY01 for review, good suggestion!
It looks like similar to this comments:
#16249 (comment)

I will try to address it, and we can get the new benchmark result!

…eam_arrow_coalesce

zhuqi-lucas · 2025-08-13T11:01:22Z

Updated: addressed the comments from @2010YOUY01 , may be we can trigger a new benchmark to see the result @alamb, thanks a lot!

alamb · 2025-08-13T20:46:59Z

🤖 ./gh_compare_branch.shBenchmark Script Running
Linux aal-dev 6.11.0-1016-gcp #16~24.04.1-Ubuntu SMP Wed May 28 02:40:52 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing revive_to_use_upstream_arrow_coalesce (4e31d7b) to 0b7186ediff using: tpch_mem
Results will be posted here when complete

alamb · 2025-08-13T20:48:08Z

 self.total_rows += batch.num_rows();
 self.inner.push_batch(batch)?;
+
+ // If the number of rows in the current batch exceeds the coalesce size,


if this turns out to work well, maybe it would be a good heuristic to add to the underlying coalescer too in non strict mode 🤔

alamb · 2025-08-13T21:18:13Z

🤖: Benchmark completed

Details

Comparing HEAD and revive_to_use_upstream_arrow_coalesce
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ revive_to_use_upstream_arrow_coalesce ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 1 │ 97.06 ms │ 83.14 ms │ +1.17x faster │
│ QQuery 2 │ 20.75 ms │ 23.00 ms │ 1.11x slower │
│ QQuery 3 │ 32.13 ms │ 35.53 ms │ 1.11x slower │
│ QQuery 4 │ 18.36 ms │ 19.71 ms │ 1.07x slower │
│ QQuery 5 │ 49.02 ms │ 55.08 ms │ 1.12x slower │
│ QQuery 6 │ 11.81 ms │ 11.65 ms │ no change │
│ QQuery 7 │ 89.03 ms │ 94.83 ms │ 1.07x slower │
│ QQuery 8 │ 23.60 ms │ 25.81 ms │ 1.09x slower │
│ QQuery 9 │ 52.99 ms │ 56.22 ms │ 1.06x slower │
│ QQuery 10 │ 40.33 ms │ 41.90 ms │ no change │
│ QQuery 11 │ 11.12 ms │ 11.81 ms │ 1.06x slower │
│ QQuery 12 │ 30.00 ms │ 30.29 ms │ no change │
│ QQuery 13 │ 25.83 ms │ 25.76 ms │ no change │
│ QQuery 14 │ 9.92 ms │ 10.32 ms │ no change │
│ QQuery 15 │ 18.48 ms │ 19.27 ms │ no change │
│ QQuery 16 │ 17.50 ms │ 17.95 ms │ no change │
│ QQuery 17 │ 97.90 ms │ 99.31 ms │ no change │
│ QQuery 18 │ 186.46 ms │ 173.42 ms │ +1.08x faster │
│ QQuery 19 │ 24.07 ms │ 25.47 ms │ 1.06x slower │
│ QQuery 20 │ 31.98 ms │ 33.17 ms │ no change │
│ QQuery 21 │ 142.18 ms │ 151.87 ms │ 1.07x slower │
│ QQuery 22 │ 14.83 ms │ 14.71 ms │ no change │
└──────────────┴───────────┴───────────────────────────────────────┴───────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1045.35ms │
│ Total Time (revive_to_use_upstream_arrow_coalesce) │ 1060.21ms │
│ Average Time (HEAD) │ 47.52ms │
│ Average Time (revive_to_use_upstream_arrow_coalesce) │ 48.19ms │
│ Queries Faster │ 2 │
│ Queries Slower │ 10 │
│ Queries with No Change │ 10 │
│ Queries with Failure │ 0 │
└──────────────────────────────────────────────────────┴───────────┘

zhuqi-lucas · 2025-08-14T11:00:45Z

🤖: Benchmark completed

Details

Comparing HEAD and revive_to_use_upstream_arrow_coalesce
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ revive_to_use_upstream_arrow_coalesce ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 1 │ 97.06 ms │ 83.14 ms │ +1.17x faster │
│ QQuery 2 │ 20.75 ms │ 23.00 ms │ 1.11x slower │
│ QQuery 3 │ 32.13 ms │ 35.53 ms │ 1.11x slower │
│ QQuery 4 │ 18.36 ms │ 19.71 ms │ 1.07x slower │
│ QQuery 5 │ 49.02 ms │ 55.08 ms │ 1.12x slower │
│ QQuery 6 │ 11.81 ms │ 11.65 ms │ no change │
│ QQuery 7 │ 89.03 ms │ 94.83 ms │ 1.07x slower │
│ QQuery 8 │ 23.60 ms │ 25.81 ms │ 1.09x slower │
│ QQuery 9 │ 52.99 ms │ 56.22 ms │ 1.06x slower │
│ QQuery 10 │ 40.33 ms │ 41.90 ms │ no change │
│ QQuery 11 │ 11.12 ms │ 11.81 ms │ 1.06x slower │
│ QQuery 12 │ 30.00 ms │ 30.29 ms │ no change │
│ QQuery 13 │ 25.83 ms │ 25.76 ms │ no change │
│ QQuery 14 │ 9.92 ms │ 10.32 ms │ no change │
│ QQuery 15 │ 18.48 ms │ 19.27 ms │ no change │
│ QQuery 16 │ 17.50 ms │ 17.95 ms │ no change │
│ QQuery 17 │ 97.90 ms │ 99.31 ms │ no change │
│ QQuery 18 │ 186.46 ms │ 173.42 ms │ +1.08x faster │
│ QQuery 19 │ 24.07 ms │ 25.47 ms │ 1.06x slower │
│ QQuery 20 │ 31.98 ms │ 33.17 ms │ no change │
│ QQuery 21 │ 142.18 ms │ 151.87 ms │ 1.07x slower │
│ QQuery 22 │ 14.83 ms │ 14.71 ms │ no change │
└──────────────┴───────────┴───────────────────────────────────────┴───────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1045.35ms │
│ Total Time (revive_to_use_upstream_arrow_coalesce) │ 1060.21ms │
│ Average Time (HEAD) │ 47.52ms │
│ Average Time (revive_to_use_upstream_arrow_coalesce) │ 48.19ms │
│ Queries Faster │ 2 │
│ Queries Slower │ 10 │
│ Queries with No Change │ 10 │
│ Queries with Failure │ 0 │
└──────────────────────────────────────────────────────┴───────────┘

cc @alamb @2010YOUY01 It seems still regression after addressing the comments. I need more investigation and try.

alamb · 2025-08-14T11:45:55Z

Man this one is tricky -- like many performance optimization quests, it will likely take careful engineering and investigation. It is fascinating to me that what in theory should be a net neutral change is turning out to be slower in some cases

zhuqi-lucas · 2025-08-14T15:14:04Z

Man this one is tricky -- like many performance optimization quests, it will likely take careful engineering and investigation. It is fascinating to me that what in theory should be a net neutral change is turning out to be slower in some cases

Thank you @alamb , i still not give up until now:

Submitted another try here:

#17193

Can i get a benchmark for this PR, thanks a lot!

alamb · 2025-08-22T13:14:55Z

superceded by #17193

alamband others added 23 commits June 4, 2025 09:01

Pin toapache/arrow-rs#7597
9a161d2

Update pin
083931d

Use upstream BatchCoalescer
e79454f

Update the pin
4e8e1ce

Update tests
9e20973

Update rev
8918b3c

Update rev
49cb62e

New rev
140ee9c

New rev
5d5683c

New rev
f79dd09

cargo fmt
1c44c5c

update pin
ea8b700

Merge branch 'main' into alamb/test_upstream_coalesce
f2fc00b

Merge branch 'main' into alamb/test_upstream_coalesce
a36065e

Merge remote-tracking branch 'apache/main' into alamb/test_upstream_c…
423137a
…oalesce

Temp pin toapache/arrow-rs#7650
1c61513

Update plans for smaller parquet files
ed31ce1

Merge remote-tracking branch 'apache/main' into alamb/test_upstream_c…
5349c73
…oalesce

update pin
c5bb25e

Merge remote-tracking branch 'upstream/main' into revive_to_use_upstr…
2f94a22
…eam_arrow_coalesce

fix test
fe7e6a3

fix
0832ff4

Merge branch 'main' into revive_to_use_upstream_arrow_coalesce
396ef3c

github-actionsBot added core Core DataFusion crate sqllogictest SQL Logic Tests (.slt) physical-plan Changes to the physical-plan crate labels Aug 9, 2025

zhuqi-lucas changed the title ~~Revive to use upstream arrow coalesce~~Feat: Revive to use upstream arrow coalesce (https://github.com/apache/datafusion/pull/16249)Aug 9, 2025

zhuqi-lucas changed the title ~~Feat: Revive to use upstream arrow coalesce (https://github.com/apache/datafusion/pull/16249)~~Feat: Revive to use upstream arrow coalesce [original PR](https://github.com/apache/datafusion/pull/16249)Aug 9, 2025

zhuqi-lucas changed the title ~~Feat: Revive to use upstream arrow coalesce [original PR](https://github.com/apache/datafusion/pull/16249)~~Feat: Revive to use upstream arrow coalesce (original PR)[https://github.com/apache/datafusion/pull/16249]Aug 9, 2025

zhuqi-lucas changed the title ~~Feat: Revive to use upstream arrow coalesce (original PR)[https://github.com/apache/datafusion/pull/16249]~~Feat: Revive to use upstream arrow coalesceAug 9, 2025

alamb mentioned this pull request Aug 11, 2025
[coalesce] Implement specialized BatchCoalescer::push_batch_with_filter for primitive array apache/arrow-rs#7762
Closed

alamb self-requested a review August 11, 2025 19:19

This was referenced Aug 12, 2025
feat: Support exact size config for BatchCoalescer apache/arrow-rs#8112
Closed
Draft: Test non exact size batch #17136
Closed

zhuqi-lucas added 2 commits August 13, 2025 16:39

Merge remote-tracking branch 'upstream/main' into revive_to_use_upstr…
c88085b
…eam_arrow_coalesce

address new comments
940d49d

Merge branch 'main' into revive_to_use_upstream_arrow_coalesce
4e31d7b

alamb reviewed Aug 13, 2025
View reviewed changes

Merge branch 'main' into revive_to_use_upstream_arrow_coalesce
49ec6e8

zhuqi-lucas mentioned this pull request Aug 14, 2025
Use the upstream arrow-rs coalesce kernel #17193
Merged

alamb mentioned this pull request Aug 22, 2025
Draft: Use upstream arrow coalesce kernel in DataFusion #16249
Closed

Merge branch 'main' into revive_to_use_upstream_arrow_coalesce
5589af0

alamb closed this Aug 22, 2025

Uh oh!

Conversation

zhuqi-lucas commented Aug 9, 2025• edited by alamb 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!

alamb commented Aug 11, 2025

Uh oh!

alamb commented Aug 11, 2025

Uh oh!

alamb commented Aug 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhuqi-lucas commented Aug 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alamb commented Aug 11, 2025

Uh oh!

zhuqi-lucas commented Aug 11, 2025

Uh oh!

zhuqi-lucas commented Aug 12, 2025

Uh oh!

2010YOUY01 commented Aug 13, 2025

Uh oh!

zhuqi-lucas commented Aug 13, 2025

Uh oh!

zhuqi-lucas commented Aug 13, 2025

Uh oh!

alamb commented Aug 13, 2025

Uh oh!

alambAug 13, 2025

Choose a reason for hiding this comment

Uh oh!

alamb commented Aug 13, 2025

Uh oh!

zhuqi-lucas commented Aug 14, 2025

Uh oh!

alamb commented Aug 14, 2025

Uh oh!

zhuqi-lucas commented Aug 14, 2025

Uh oh!

alamb commented Aug 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

zhuqi-lucas commented Aug 9, 2025•
edited by alamb
Loading

alamb commented Aug 11, 2025•
edited
Loading

zhuqi-lucas commented Aug 11, 2025•
edited
Loading