# Another rechunking algorithm

**URL:** <https://discourse.pangeo.io/t/another-rechunking-algorithm/5227>\
**Category:** HPC\
**Created:** [July 1, 2025, 10:32pm UTC](https://discourse.pangeo.io/t/another-rechunking-algorithm/5227 "2025-07-01T22:32:50Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![TomNicholas](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.pangeo.io/tomnicholas/32/3189_2.png) [@TomNicholas](https://discourse.pangeo.io/u/TomNicholas)\
**Post date:** [July 3, 2025, 2:39pm UTC](https://discourse.pangeo.io/t/another-rechunking-algorithm/5227/6 "2025-07-03T14:39:55Z")

</div>

@mullenkamp also see this discussion for further context

> [@Why learn rust? A pangeo perspective](https://discourse.pangeo.io/t/why-learn-rust-a-pangeo-perspective/4649/9):
>
> I think we’re actually very close to this already using Cubed. You can already [run Cubed today on a single machine](https://github.com/cubed-dev/cubed/issues/492#issuecomment-2238908343) utilizing all cores (through threads or processes), and it internally creates a query plan that it optimizes. By default, it would keep intermediate arrays in RAM; unless this would result in running out of RAM. In which case it’d borrow from Cubed’s approach, and write intermediate data to disk. Doing the rechunk in-memory is the only part that’s missing. A while ago [I raised …](https://github.com/cubed-dev/cubed/issues/502)

---

_[View the full topic](https://discourse.pangeo.io/t/another-rechunking-algorithm/5227)._