Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move keyspace utils into Key impl #6438

Closed
VladLazar opened this issue Jan 22, 2024 · 1 comment · Fixed by #7929
Closed

Move keyspace utils into Key impl #6438

VladLazar opened this issue Jan 22, 2024 · 1 comment · Fixed by #7929
Labels
c/storage/pageserver Component: storage: pageserver

Comments

@VladLazar
Copy link
Contributor

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)

@koivunej
Copy link
Member

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).

arpad-m added a commit that referenced this issue Jun 3, 2024
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 #7890
Fixes #6438
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/storage/pageserver Component: storage: pageserver
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants