- 11 Jun, 2020 2 commits
-
-
antirez authored
-
-
- 10 Jun, 2020 2 commits
-
-
antirez authored
-
Paul Spooren authored
The `LRANK` command returns the index (position) of a given element within a list. Using the `direction` argument it is possible to specify going from head to tail (acending, 1) or from tail to head (decending, -1). Only the first found index is returend. The complexity is O(N). When using lists as a queue it can be of interest at what position a given element is, for instance to monitor a job processing through a work queue. This came up within the Python `rq` project which is based on Redis[0]. [0]: https://github.com/rq/rq/issues/1197 Signed-off-by:
Paul Spooren <mail@aparcar.org>
-
- 21 Apr, 2020 1 commit
-
-
antirez authored
-
- 22 Nov, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 05 Sep, 2019 1 commit
-
-
antirez authored
-
- 02 Sep, 2019 1 commit
-
-
antirez authored
-
- 07 May, 2019 1 commit
-
-
stan011 authored
-
- 14 Mar, 2019 1 commit
-
-
Guy Benoish authored
-
- 09 Jan, 2019 4 commits
- 28 Sep, 2018 1 commit
-
-
zhaozhao.zz authored
There are two problems if we use lastcmd: 1. BRPOPLPUSH cannot be rewrited as RPOPLPUSH in multi/exec In mulit/exec context, the lastcmd is exec. 2. Redis will crash when execute RPOPLPUSH loading from AOF In fakeClient, the lastcmd is NULL.
-
- 14 Aug, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 22 Mar, 2018 1 commit
-
-
Guy Benoish authored
-
- 01 Dec, 2017 2 commits
- 20 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 10 Jun, 2016 1 commit
-
-
antirez authored
All lists are now represented via quicklists. Quicklists are never represented referencing robj structures, so trying to compress their representation does not make sense. That the new way is faster was experimentally verified with micro benchmarks in order to prove that the intuition was correct.
-
- 05 Jun, 2016 3 commits
-
-
Pierre Chapuis authored
-
Pierre Chapuis authored
-
Pierre Chapuis authored
-
- 02 Feb, 2016 1 commit
-
-
Itamar Haber authored
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 5 commits
- 02 Jan, 2015 3 commits
-
-
Matt Stancliff authored
This removes: - list-max-ziplist-entries - list-max-ziplist-value This adds: - list-max-ziplist-size - list-compress-depth Also updates config file with new sections and updates tests to use quicklist settings instead of old list settings.
-
Matt Stancliff authored
Let user set how many nodes to *not* compress. We can specify a compression "depth" of how many nodes to leave uncompressed on each end of the quicklist. Depth 0 = disable compression. Depth 1 = only leave head/tail uncompressed. - (read as: "skip 1 node on each end of the list before compressing") Depth 2 = leave head, head->next, tail->prev, tail uncompressed. - ("skip 2 nodes on each end of the list before compressing") Depth 3 = Depth 2 + head->next->next + tail->prev->prev - ("skip 3 nodes...") etc. This also: - updates RDB storage to use native quicklist compression (if node is already compressed) instead of uncompressing, generating the RDB string, then re-compressing the quicklist node. - internalizes the "fill" parameter for the quicklist so we don't need to pass it to _every_ function. Now it's just a property of the list. - allows a runtime-configurable compression option, so we can expose a compresion parameter in the configuration file if people want to trade slight request-per-second performance for up to 90%+ memory savings in some situations. - updates the quicklist tests to do multiple passes: 200k+ tests now.
-
Matt Stancliff authored
This replaces individual ziplist vs. linkedlist representations for Redis list operations. Big thanks for all the reviews and feedback from everybody in https://github.com/antirez/redis/pull/2143
-
- 10 Dec, 2014 1 commit
-
-
antirez authored
Slaves key expire is orchestrated by the master. Sometimes the master will send the synthesized DEL to expire keys on the slave with a non trivial delay (when the key is not accessed, only the incremental expiry algorithm will expire it in background). During that time, a key is logically expired, but slaves still return the key if you GET (or whatever) it. This is a bad behavior. However we can't simply trust the slave view of the key, since we need the master to be able to send write commands to update the slave data set, and DELs should only happen when the key is expired in the master in order to ensure consistency. However 99.99% of the issues with this behavior is when a client which is not a master sends a read only command. In this case we are safe and can consider the key as non existing. This commit does a few changes in order to make this sane: 1. lookupKeyRead() is modified in order to return NULL if the above conditions are met. 2. Calls to lookupKeyRead() in commands actually writing to the data set are repliaced with calls to lookupKeyWrite(). There are redundand checks, so for example, if in "2" something was overlooked, we should be still safe, since anyway, when the master writes the behavior is to don't care about what expireIfneeded() returns. This commit is related to #1768, #1770, #2131.
-
- 26 Jun, 2014 1 commit
-
-
antirez authored
-
- 21 May, 2014 1 commit
-
-
Matt Stancliff authored
Behrad Zari discovered [1] and Josiah reported [2]: if you block and wait for a list to exist, but the list creates from a non-push command, the blocked client never gets notified. This commit adds notification of blocked clients into the DB layer and away from individual commands. Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE, and RESTORE. Previously, blocked client notifications were only triggered by [LR]PUSH. Your client would never get notified if a list were created by SORT..STORE or RENAME or a RESTORE, etc. Blocked client notification now happens in one unified place: - dbAdd() triggers notification when adding a list to the DB Two new tests are added that fail prior to this commit. All test pass. Fixes #1668 [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU [2]: #1668
-
- 10 Dec, 2013 1 commit
-
-
antirez authored
Redis hash table implementation has many non-blocking features like incremental rehashing, however while deleting a large hash table there was no way to have a callback called to do some incremental work. This commit adds this support, as an optiona callback argument to dictEmpty() that is currently called at a fixed interval (one time every 65k deletions).
-
- 05 Dec, 2013 1 commit
-
-
antirez authored
-
- 03 Dec, 2013 1 commit
-
-
antirez authored
-