Hello, I have a question regarding Client-Side Caching Server Side Implementation, in https://github.com/redis/redis/blob/unstable/src/tracking.c#L360, trackingInvalidateKeysOnFlush function, we sent out tracking invalidation messages to all the clients which enabled tracking, no matter whether it is FLUSHDB or FLUSHALL case. however, Why we only clean up the tracking table for FLUSHALL case only? I think we can safely clean up the tracking table no matter whether it is FLUSHDB or FLUSHALL case, since the invalidation message for both cases are sending out, and this feature doesn't distinguish for DB. Or am I missing something? Thanks!
Comment From: madolson
We could. Cleaning up the tracking table is expensive, (It used to be way more expensive and have a higher fixed cost) so the original implementation was to only do it for FLUSHALL and let the FlushDB case naturally let the clients get invalidated. I think now we should probably clean it up completely on both cases.
Comment From: daidaotong
@madolson thank you! I think we should clean up the tracking table in both cases, otherwise, there is a big chance that the tracking table memory usage can grow up quickly if we are using FLUSHDB all the time. but it is worth thinking about how we can amortize the cost for freeing the tracking table when the time cost is high. Thanks!
Comment From: madolson
To understand the impact here, @daidaotong is that a use case for you or are you just thinking about some potential edge cases?
Comment From: daidaotong
Hi @madolson, thanks, in my side, there are no use cases for this part. This is just brainstorming potential issues if we decided to move forward with this.