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
There is an lskey action, but it must to declare a size for lskey action. if skytable support an api like filterkey, i think it's very useful.
In fact, in the process of retrieving the key, I first call lskey, give it a large enough value, and then filter the results. If we built it into the action, then we can easily retrieve and filter the key.
The text was updated successfully, but these errors were encountered:
While a filtering API would be trivial to write, the time complexity of the function would be O(n) (n=size of dataset). In your use case, would such a performance penalty be acceptable?
In other cases, indexing would be the solution (but again scaling indexes in a distributed environment is another challenge; but that's something we're working on)
@ohsayan Agree with your point. However, the actual situation is different. In my usage scenario, the KEY collection is not too large, and index or full scan filtering is acceptable in performance observation.
Description
There is an
lskey
action, but it must to declare asize
forlskey
action. if skytable support an api likefilterkey
, i think it's very useful.In fact, in the process of retrieving the key, I first call lskey, give it a large enough value, and then filter the results. If we built it into the action, then we can easily retrieve and filter the key.
The text was updated successfully, but these errors were encountered: