Hi, we once did some extensive performance testing on the row cache (motivated by some hardware accelerator we were hoping to introduce) but could only find improvements in highly contrived scenarios - has been a while since then so fresh eyes are good but I think we will still arrive at the conclusion to deprecate the row cache.
Thanks, German ________________________________ From: Jon Haddad <j...@jonhaddad.com> Sent: Monday, December 18, 2023 10:31 AM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: [EXTERNAL] Re: Future direction for the row cache and OHC implementation You don't often get email from j...@jonhaddad.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Sure, I’d love to work with you on this. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com<http://rustyrazorblade.com/> On Mon, Dec 18, 2023 at 8:30 AM Ariel Weisberg <ar...@weisberg.ws<mailto:ar...@weisberg.ws>> wrote: Hi, Thanks for the generous offer. Before you do that can you give me a chance to add back support for Caffeine for the row cache so you can test the option of switching back to an on-heap row cache? Ariel On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote: I think we should probably figure out how much value it actually provides by getting some benchmarks around a few use cases along with some profiling. tlp-stress has a --rowcache flag that I added a while back to be able to do this exact test. I was looking for a use case to profile and write up so this is actually kind of perfect for me. I can take a look in January when I'm back from the holidays. Jon On Thu, Dec 14, 2023 at 5:44 PM Mick Semb Wever <m...@apache.org<mailto:m...@apache.org>> wrote: I would avoid taking away a feature even if it works in narrow set of use-cases. I would instead suggest - 1. Leave it disabled by default. 2. Detect when Row Cache has a low hit rate and warn the operator to turn it off. Cassandra should ideally detect this and do it automatically. 3. Move to Caffeine instead of OHC. I would suggest having this as the middle ground. Yes, I'm ok with this. (2) can also be a guardrail: soft value when to warn, hard value when to disable.
