pub struct Zset { /* private fields */ }Expand description
A set of members, each with a score, ordered by score and then by member.
Implementations§
Source§impl Zset
impl Zset
Sourcepub fn with_hint(hint: usize, limits: &Limits) -> Zset
pub fn with_hint(hint: usize, limits: &Limits) -> Zset
An empty sorted set with room for hint members.
A caller that knows the count up front, which is every RESTORE, should
not fill the packed band to its limit and then promote the lot into a
table. That pays a scan for the member and a scan for the position on
every one of the first hundred and twenty eight, and then throws the
listpack away.
The hint is only a hint. Being wrong about it costs a table with more room than it needed rather than anything incorrect, and a hint under the band limit still gets the band, because a sorted set that turns out to be small is the common one and it should stay packed.
Sourcepub fn freeze(&self, out: &mut Vec<u8>)
pub fn freeze(&self, out: &mut Vec<u8>)
Write this sorted set out in a form a device can hold.
The packed band goes out as its own bytes, and the table goes out as its members in rank order, each one followed by its score. Rank order is the point of writing it that way: the order is the expensive half of a sorted set, and a body written in order comes back without a single comparison.
A score is eight raw bytes rather than the text a listpack holds, because the table has the double already and formatting it here only to parse it on the way back would cost two conversions for no saving.
Sourcepub fn thaw(bytes: &[u8]) -> Result<Zset, Broken>
pub fn thaw(bytes: &[u8]) -> Result<Zset, Broken>
Read back what Zset::freeze wrote.
The band a sorted set left in is the band it comes back in, so a value
that was quiet long enough to be moved out answers OBJECT ENCODING with
the same word it answered before.
Sourcepub fn memory_bytes(&self) -> usize
pub fn memory_bytes(&self) -> usize
What this is holding on to, in bytes.
Sourcepub fn score(&self, member: &[u8]) -> Option<f64>
pub fn score(&self, member: &[u8]) -> Option<f64>
The score of a member, or None if it is not in here.
ZSCORE, and the first half of every ZADD.
Sourcepub fn add(&mut self, member: &[u8], score: f64, limits: &Limits) -> Added
pub fn add(&mut self, member: &[u8], score: f64, limits: &Limits) -> Added
Put a member in, or move one that is already there.
Sourcepub fn remove(&mut self, member: &[u8]) -> bool
pub fn remove(&mut self, member: &[u8]) -> bool
Take a member out.
ZREM, and the way ZADD GT gets rid of nothing at all.
Sourcepub fn rank(&self, member: &[u8]) -> Option<usize>
pub fn rank(&self, member: &[u8]) -> Option<usize>
Where a member sits, counting from the lowest score.
ZRANK, and ZREVRANK by taking it from the length.
Sourcepub fn at(&self, rank: usize) -> Option<(Member<'_>, f64)>
pub fn at(&self, rank: usize) -> Option<(Member<'_>, f64)>
The member and score at a rank.
The member is not copied. ZPOPMIN writes it into the reply and then
calls Zset::remove_at with the same rank, which is why these are two
methods and not one that hands back an owned name.
Sourcepub fn pick(&self, at: usize) -> Option<(Member<'_>, f64)>
pub fn pick(&self, at: usize) -> Option<(Member<'_>, f64)>
A member by position in no particular order, for a uniform draw.
ZRANDMEMBER wants any member with equal probability and does not care
which, so on the table this reads a row straight out of the dense array
rather than descending the tree for a rank nobody asked for.
Sourcepub fn walk<F: FnMut(Member<'_>, f64)>(
&self,
from: usize,
count: usize,
rev: bool,
f: F,
)
pub fn walk<F: FnMut(Member<'_>, f64)>( &self, from: usize, count: usize, rev: bool, f: F, )
Walk members in rank order, from a rank, for a count.
Every range command comes through here after working out which ranks it wants, because a range by score and a range by member are the same walk once the two ends have been found.
Sourcepub fn window_by_score(&self, min: Bound, max: Bound) -> Range<usize> ⓘ
pub fn window_by_score(&self, min: Bound, max: Bound) -> Range<usize> ⓘ
The ranks whose scores fall inside a range.
ZRANGEBYSCORE, ZCOUNT and ZREMRANGEBYSCORE are all this plus a walk
or a count of what it returns. An empty range comes back as an empty one
rather than as a pair that has to be checked by the caller.
Sourcepub fn window_by_lex(&self, min: Lex<'_>, max: Lex<'_>) -> Range<usize> ⓘ
pub fn window_by_lex(&self, min: Lex<'_>, max: Lex<'_>) -> Range<usize> ⓘ
The ranks whose members fall inside a range, ignoring scores.
ZRANGEBYLEX, which is only meaningful when every member has the same
score and is nonsense otherwise, exactly as it is in Redis.
Sourcepub fn scan<F: FnMut(Member<'_>, f64)>(
&self,
cursor: Cursor,
count: usize,
f: F,
) -> Cursor
pub fn scan<F: FnMut(Member<'_>, f64)>( &self, cursor: Cursor, count: usize, f: F, ) -> Cursor
Walk members for ZSCAN, in whatever order the storage has them in.
Sourcepub fn from_elements(members: Elements<f64>, limits: &Limits) -> Option<Zset>
pub fn from_elements(members: Elements<f64>, limits: &Limits) -> Option<Zset>
Build a sorted set out of a member to score table that is in no order.
This is what the algebra next door hands back. ZUNIONSTORE works out
every member’s final score in a table that knows nothing about order,
because a member appearing in a fourth input should be a hash probe and
not a pair of tree descents, and then this puts the whole thing in order
once at the end.
The table is not read and copied, it is moved in and becomes the sorted set. Every member’s bytes were written when the first input holding that member was walked and they are never touched again, which is the thing that makes a union of four large sets one pass over each of them and one sort, rather than a pass and a rebuild.
Answers nothing for an empty table, because an empty sorted set does not exist and the caller’s key should be deleted rather than made.