- 15 Mar, 2018 25 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
We need to check if we are going to serve the request via the PEL before inserting a deferred array len in the client output buffer.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 01 Mar, 2018 1 commit
-
-
antirez authored
-
- 04 Dec, 2017 1 commit
-
-
antirez authored
-
- 01 Dec, 2017 13 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
After checking with the community via Twitter (here: https://twitter.com/antirez/status/915130876861788161) the verdict was to use ":". However I later realized, after users lamented the fact that it's hard to copy IDs just with double click, that this was the reason why I moved to "." in the first instance. Fortunately "-", that was the other option with most votes, also gets selected with double click on most terminal applications on Linux and MacOS. So my reasoning was: 1) We can't retain "." because it's actually confusing to newcomers, it looks like a floating number, people may be tricked into thinking they can order IDs numerically as floats. 2) Moving to a double-click-to-select format is much better. People will work with such IDs for long time when coding / debugging. Why making now a choice that will impact this for the next years? The only other viable option was "-", and that's what I did. Thanks.
-
antirez authored
Clang should be more prone to return warnings by default when there is same-var-name shadowing. GCC does this and can avoid bugs like that.
-
antirez authored
-
antirez authored
-
antirez authored
The core of this change is the implementation of stream trimming, and the resulting MAXLEN option of XADD as a trivial result of having trimming functionalities. MAXLEN already works but in order to be more efficient listpack GC should be implemented, currently marked as a TODO item inside the comments.
-
antirez authored
Listpack max size is a tradeoff between space and time. A 2k max entry puts the memory usage approximately at a similar order of magnitude (5 million entries went from 96 to 120 MB), but the range queries speed doubled (because there are half entries to scan in the average case). Lower values could be considered, or maybe this parameter should be made tunable.
-