Ran Shidlansik

Thank you @otheng03. I am still not sure I understand how the user will react or use this data: > Support for bigkeylog will enable user to check out which...

>As the workload of a user's service changes, unexpectedly large keys can become a risk factor that impacts performance. (Users may not know how large their stored hashes or lists...

> > [@otheng03](https://github.com/otheng03) As I agree the feature proposal to have a server-side tool to track down big/large keys is important, I am not sure I understand the details of...

I agree that maintaining some list/hash of largest keys is a good idea, no argue about that. I only meant that we should base this only on key memory consumption...

I agree regarding the extended effort needed in this case. I think we should provide some sort of mask-pii mode for redis so it will avoid reporting internal data (key...

> > but we will also need to provide the customer way to get that data in case he needs it > > Customer will be able to watch those...

> Not a fan of the idea, but It could be an acl user flag. This way an existing monitoring application will not require modifications (like the above multi) >...

> @ranshid I think we need to consider the use case you describe as a separate feature. Preventing PII from getting into log files is one thing. Removing PII from...

Very interesting. We know for sure that the CPU consumption is not linear with the QPS growth (as you correctly stated due to improvements such as batch prefetching). It is...

> a) let's target this for Valkey 10.0. this gives us the time to get the design right, build consensus, and test it thoroughly. a change of this magnitude deserves...