Skip to content

Conversation

timvisee
Copy link
Member

@timvisee timvisee commented Mar 26, 2025

Fixes incorrect implementation in #6084.

The function to calculate the fraction of points transferred during a resharding transfer was incorrect. For resharding up it gave us the wrong result.

For resharding up, the returned fraction was for the total number of points in the collection, not a fraction for the number of points in the current shard like the function describes.

Long story short, this fixed the fraction calculation. The documentation with examples has been updated as well.

In practice this fixes our point count estimate in shard transfers. It's not critical, but helpful to do proper transfer estimations.

All Submissions:

  • Contributions should target the dev branch. Did you create your branch from dev?
  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

  1. Does your submission pass tests?
  2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
  3. Have you checked your code using cargo clippy --all --all-features command?

This comment was marked as resolved.

// - shards: 3 -> 4
// points: 33/33/33 -> 25/25/25/25
// transfer fraction of each shard: 1/4/3 = 0.083
Ordering::Less => (1.0 / to as f32) / (from as f32),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The final / from here was wrong. It adjusted the factor from shard level to collection level, which was not correct.

@timvisee timvisee force-pushed the resharding-fix-point-fraction branch from 5f56cc3 to fe11d80 Compare March 26, 2025 12:41
Copy link
Member

@KShivendu KShivendu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the quick update!

Copy link
Contributor

@ffuugoo ffuugoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but do we even need this method on HashRing? Can't we just derive this from resharding state? It's literally just points_in_shard / new_shard_count, no point in calculating f32 multiplier.

@timvisee
Copy link
Member Author

timvisee commented Mar 26, 2025

LGTM, but do we even need this method on HashRing? Can't we just derive this from resharding state? It's literally just points_in_shard / new_shard_count, no point in calculating f32 multiplier.

Yes. With the previous (wrong 🤡) implementation it was a bit more complex, and the plan was to use it in two places. But now that it's simpler I'll move it directly into the call site instead. 👍

@timvisee timvisee requested a review from ffuugoo March 26, 2025 14:08
Copy link
Contributor

@ffuugoo ffuugoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@timvisee timvisee merged commit 6c7e5a0 into dev Mar 26, 2025
17 checks passed
@timvisee timvisee deleted the resharding-fix-point-fraction branch March 26, 2025 14:55
timvisee added a commit that referenced this pull request Mar 31, 2025
)

* Fix incorrect resharding transfer fraction for points to transfer

* Explicitly handle case where from and to are the same

* Update lib/collection/src/hash_ring.rs

Co-authored-by: Kumar Shivendu <kshivendu1@gmail.com>

* Move point fraction calculation right into the call site

* Don't use intermediate f64

---------

Co-authored-by: Kumar Shivendu <kshivendu1@gmail.com>
@timvisee timvisee mentioned this pull request Mar 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants