- 20 Jul, 2016 2 commits
- 15 Jul, 2016 1 commit
-
-
antirez authored
Implementation of LFU maxmemory policy for anything related to Redis objects. Still no actual eviction implemented.
-
- 13 Jul, 2016 1 commit
-
-
antirez authored
The LRU eviction code used to make local choices: for each DB visited it selected the best key to evict. This was repeated for each DB. However this means that there could be DBs with very frequently accessed keys that are targeted by the LRU algorithm while there were other DBs with many better candidates to expire. This commit attempts to fix this problem for the LRU policy. However the TTL policy is still not fixed by this commit. The TTL policy will be fixed in a successive commit. This is an initial (partial because of TTL policy) fix for issue #2647.
-
- 12 Jul, 2016 2 commits
- 06 Jul, 2016 1 commit
-
-
antirez authored
-
- 04 Jul, 2016 1 commit
-
-
antirez authored
We already changed the default in the redis.conf template, but I forgot to change the internal config as well.
-
- 01 Jul, 2016 1 commit
-
-
antirez authored
-
- 22 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 20 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 14 Jun, 2016 1 commit
-
-
antirez authored
-
- 13 Jun, 2016 2 commits
- 05 Jun, 2016 2 commits
-
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
-
- 03 Jun, 2016 1 commit
-
-
antirez authored
-
- 01 Jun, 2016 1 commit
-
-
antirez authored
-
- 18 May, 2016 1 commit
-
-
antirez authored
-
- 10 May, 2016 9 commits
- 09 May, 2016 1 commit
-
-
oranagra authored
-
- 25 Apr, 2016 1 commit
-
-
Oran Agra authored
-
- 22 Apr, 2016 1 commit
-
-
therealbill authored
I've renamed maxmemoryToString to evictPolicyToString since that is more accurate (and easier to mentally connect with the correct data), as well as updated the function to user server.maxmemory_policy rather than server.maxmemory. Now with a default config it is actually returning the correct policy rather than volatile-lru.
-
- 15 Apr, 2016 2 commits
- 14 Apr, 2016 1 commit
-
-
antirez authored
-
- 26 Feb, 2016 1 commit
-
-
antirez authored
The new bitfield command is an extension to the Redis bit operations, where not just single bit operations are performed, but the array of bits composing a string, can be addressed at random, not aligned offsets, with any width unsigned and signed integers like u8, s5, u10 (up to 64 bit signed integers and 63 bit unsigned integers). The BITFIELD command supports subcommands that can SET, GET, or INCRBY those arbitrary bit counters, with multiple overflow semantics. Trivial and credits: A similar command was imagined a few times in the past, but for some reason looked a bit far fetched or not well specified. Finally the command was proposed again in a clear form by Yoav Steinberg from Redis Labs, that proposed a set of commands on arbitrary sized integers stored at bit offsets. Starting from this proposal I wrote an initial specification of a single command with sub-commands similar to what Yoav envisioned, using short names for types definitions, and adding control on the overflow. This commit is the resulting implementation. Examples: BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
-
- 18 Feb, 2016 2 commits
- 29 Jan, 2016 3 commits