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

etcdserver: add skip param to RangeRequest #16544

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jjz921024
Copy link

@jjz921024 jjz921024 commented Sep 5, 2023

Add skip param for skip the first N kvs returned

Current, range query only limit the number of returned. This feature allows user query in batches for a lot of special prefix key.

Signed-off-by: jjz921024 [email protected]

@@ -494,6 +494,9 @@ message RangeRequest {
// max_create_revision is the upper bound for returned key create revisions; all keys with
// greater create revisions will be filtered away.
int64 max_create_revision = 13 [(versionpb.etcd_version_field)="3.1"];

// skip is the skip the first N keys returned for the request.
int64 skip = 14;
Copy link
Member

Choose a reason for hiding this comment

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

. This feature allows user query in batches for a lot of special prefix key.

Can't follow your idea here. Would you try to use different range setting [key_start, key_end) to handle it?
If you know what the value of skip is, I think you can adjust the key_start to achieve it.

Copy link
Author

Choose a reason for hiding this comment

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

I know you meant. but sometime i can't get next key_start.

i try to implement redis scan command base on etcd, the scan iterate data based on the cursor,
for scan 1000 count 10, I don't know the start_key after the first 1000th element
and i have to query the full amount of data to do this

Copy link
Member

Choose a reason for hiding this comment

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

Not sure that I understand it correctly:

Assume that the target is [foo::000000, foo:999999). You can use Range API with limit 1000 and key-only option.
If there is mroe than 1000 key/values, the last key in the response is the target 1000th element you want.

Does it make sense to you?

Copy link
Author

@jjz921024 jjz921024 Sep 6, 2023

Choose a reason for hiding this comment

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

I understand. This parameter is not necessary, but is useful for some scenarios.

If I want to implement a middleware that batches queries by cursor, and I don't want to maintain the cursor and key relationship.

The first query is for the first 10 key. It is ok, but I don't want to remember which key is the 10th.
The second query I want to seek the 10th key by cursor. For example, the redis command scan 10 limit 10. In this scenario,I have to query the first 20 keys, then ignore the first 10 and return the query

Copy link
Member

Choose a reason for hiding this comment

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

I have to query the first 20 keys, then ignore the first 10 and return the query

If I understand correctly, the skip param is to let the server do that. :)
Well, it might need to introduce new API for this if necessary.

Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Mar 17, 2024
@stale stale bot removed the stale label Jun 11, 2024
@k8s-ci-robot
Copy link

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants