Conversation
The existing API for the Bloom Filter constructor was, huh, not ideal. There is no need to use variable args and check the values of the args for their meaning. Signed-off-by: Vicent Marti <vmg@strn.cat>
Signed-off-by: Vicent Marti <vmg@strn.cat>
vmg
requested review from
harshit-gangal,
shlomi-noach,
sougou and
systay
as code owners
Signed-off-by: Vicent Marti <vmg@strn.cat>
Signed-off-by: Vicent Marti <vmg@strn.cat>
the '==' operator is not posix; you're supposed to use a single '=' Signed-off-by: Vicent Marti <vmg@strn.cat>
|
One thing I missed while reviewing the earlier PR was the names of the flags: There is no need to prefix the flag names with |
Signed-off-by: Vicent Marti <vmg@strn.cat>
|
@deepthi: |
Signed-off-by: Vicent Marti <vmg@strn.cat>
Signed-off-by: Vicent Marti <vmg@strn.cat>
|
OK, fixed and fixed all the flappy tests. I think this PR, which enables the LFU cache by default, is ready to merge. ✨ |
Oops, I did not realize that one of the flags was already there. I would not hold up this PR. We can rename the flags in a backwards-compatible way in a separate PR (if we decide it is worth doing). |
| MaxEntries: 5000, | ||
| MaxMemoryUsage: 32 * 1024 * 1024, | ||
| LFU: false, | ||
| LFU: true, |
| return uint64(size), uint64(locs) | ||
| // NewBloomFilterWithErrorRate returns a new bloomfilter with optimal size for the given | ||
| // error rate | ||
| func NewBloomFilterWithErrorRate(numEntries uint64, wrongs float64) *Bloom { |
Signed-off-by: Vicent Marti <vmg@strn.cat>
4 participants
Description
Some bug fixes, refactorings and more benchmarks for the LFU implementation. Getting it in better shape before we switch to it by default.
Related Issue(s)
Checklist
Deployment Notes
Impacted Areas in Vitess
Components that this PR will affect: