use integer multiple of shard shape when rechunking in to_zarr#12106
use integer multiple of shard shape when rechunking in to_zarr#12106
Conversation
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 9 files ± 0 9 suites ±0 3h 9m 45s ⏱️ + 4m 47s Results for commit 1b6ccd6. ± Comparison against base commit 06e75c7. This pull request removes 1 and adds 4 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
I think a performance warning would be ok. There's just always a tradeoff with chunks="auto"... |
|
@dcherian really appreciate your reviews here. I had a chat with other Dask maintainers and we would like to give you contributor access to this repo. Please feel empowered to review and merge PRs like this one where you have expertise. |
|
Thanks @jacobtomlinson |
Co-authored-by: Deepak Cherian <dcherian@users.noreply.github.com>
Co-authored-by: Deepak Cherian <dcherian@users.noreply.github.com>
|
do we need anything else here? |
|
can you solve the merge conflict please? |
…into fix/to-zarr-sharding-2
done! |
|
I think this is right; certainly it is an improvement to write safety. So let's merge. |
Improves on #12105 by using the shard shape as the
previous_chunksparameter instead ofchunks. This results in rechunking with with larger chunks that are still shard-aligned. Thanks to @dcherian for reminding me thatauto_chunksnearly always concatenates theprevious_chunksargument.But not always. This change brings the possibility of shard-misaligned chunks if the global configuration declares a memory limit smaller than the shard size. What should we do when there's competition between the global config and shard shape of the zarr array? Would an exception be appropriate here, prompting the user to change the config?