You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see those imports. I think if we move these functions to inherent impls on the Key type then we won't need as many of them, but I think it should be a separate PR.
I wonder if we'll win much by this. While working with the "keytool" in #7890 and looking at the auxfilesv2 work happening at the same time, I started thinking that:
Before we make the relation metadata key change to be always on shard0 in finite number of layers, we should make this Key be actually structural, like a enum of the different meanings.
Then it will be easy to write the two different (v1, v2) mapping functions from this logical key to what is our less-logical key (u128).
The keyspace utils like `is_rel_size_key` or `is_rel_fsm_block_key` and
many others are free functions and have to be either imported separately
or specified with the full path starting in `pageserver_api::key::`.
This is less convenient than if these functions were just inherent
impls.
Follow-up of #7890Fixes#6438
I see those imports. I think if we move these functions to inherent impls on the
Key
type then we won't need as many of them, but I think it should be a separate PR.Originally posted by @arpad-m in #6406 (comment)
The text was updated successfully, but these errors were encountered: