- 31 Jul, 2019 1 commit
-
-
antirez authored
-
- 29 Jul, 2019 1 commit
-
-
John Sully authored
-
- 16 Mar, 2019 1 commit
-
-
antirez authored
-
- 15 Mar, 2019 3 commits
-
-
antirez authored
-
antirez authored
-
John Sully authored
-
- 09 Jan, 2019 1 commit
-
-
antirez authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 03 Jun, 2018 1 commit
-
-
Yossi Gottlieb authored
-
- 16 Mar, 2018 1 commit
-
-
antirez authored
-
- 14 Mar, 2018 1 commit
-
-
Otmar Ertl authored
-
- 11 Mar, 2018 1 commit
-
-
Otmar Ertl authored
-
- 10 Mar, 2018 4 commits
-
-
Otmar Ertl authored
-
Otmar Ertl authored
-
Otmar Ertl authored
based on method described in https://arxiv.org/abs/1702.01284 that does not rely on any magic constants
-
Otmar Ertl authored
-
- 22 Dec, 2017 3 commits
-
-
antirez authored
This is a fix for the #3819 improvements. The o->ptr may change because of hllSparseSet() calls, so 'hdr' must be correctly re-fetched.
-
antirez authored
This is a fix for #3819.
-
antirez authored
The commit splits the add functions into a set() and add() set of functions, so that it's possible to set registers in an independent way just having the index and count. Related to #3819, otherwise a fix is not possible.
-
- 11 Jul, 2017 1 commit
-
-
antirez authored
Close #3766.
-
- 23 Feb, 2017 1 commit
-
-
Salvatore Sanfilippo authored
-
- 19 Feb, 2017 2 commits
-
-
Salvatore Sanfilippo authored
However note that in architectures supporting 64 bit unaligned accesses memcpy(...,...,8) is likely translated to a simple word memory movement anyway.
-
Salvatore Sanfilippo authored
-
- 16 Dec, 2016 3 commits
-
-
antirez authored
The new algorithm provides the same speed with a smaller error for cardinalities in the range 0-100k. Before switching, the new and old algorithm behavior was studied in details in the context of issue #3677. You can find a few graphs and motivations there.
-
antirez authored
Otherwise for small cardinalities the algorithm will output something like, for example, 4.99 for a candinality of 5, that will be converted to 4 producing a huge error.
-
Harish Murthy authored
Config option to use LogLog-Beta Algorithm for Cardinality
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 5 commits
- 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.
-
- 02 Dec, 2014 1 commit
-
-
antirez authored
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 23 Jul, 2014 1 commit
-
-
antirez authored
This is just a quickfix, for the nature of the test the right way to fix it is to average the error of N runs, since otherwise it is always possible to get a false positive with a bad run, or to minimize too much this possibility we may end testing with too much "large" error ranges.
-
- 18 May, 2014 1 commit
-
-
Mike Trinkala authored
Set the MSB as documented.
-
- 17 Apr, 2014 3 commits
-
-
antirez authored
The internal HLL raw encoding used by PFCOUNT when merging multiple keys is aligned to 8 bits (1 byte per register) so we can exploit this to improve performances by processing multiple bytes per iteration. In benchmarks the new code was several times faster with HLLs with many registers set to zero, while no slowdown was observed with populated HLLs.
-
antirez authored
When the register is set to zero, we need to add 2^-0 to E, which is 1, but it is faster to just add 'ez' at the end, which is the number of registers set to zero, a value we need to compute anyway.
-
antirez authored
-