Re: [DISCUSS] CASSANDRA-18940 SAI post-filtering reads don't update local table latency metrics

[J. D. Jordan]

I prefer option 2. It is much easier to understand and roll up two metrics than to do subtractive dashboards. SAI reads are already “range reads” for the client level metrics, not regular reads. So grouping them into the regular read metrics at the lower level seems confusing to me in that sense as well. As an operator I want to know how my SAI reads and normal reads are performing latency wise separately. -Jeremiah On Dec 1, 2023, at 11:15 AM, Caleb Rackliffe <calebrackli...@gmail.com> wrote:  Option 1 would be my preference. Seems both useful to have a single metric for read load against the table and a way to break out SAI reads specifically. On Fri, Dec 1, 2023 at 11:00 AM Mike Adamson <madam...@datastax.com> wrote: Hi, We are looking at adding SAI post-filtering reads to the local table metrics and would like some feedback on the best approach. We don't think that SAI reads are that special so they can be included in the table latencies, but how do we handle the global counts and the SAI counts? Do we need to maintain a separate count of SAI reads? We feel the answer to this is yes so how do we do the counting? There are two options (others welcome): 1. All reads go into the current global count and we have a separate count for SAI specific reads. So non-SAI reads = global count - SAI count 2. We leave the exclude the SAI reads from the current global count so total reads = global count + SAI count Our preference is for option 1 above. Does anyone have any strong views / opinions on this?  -- Mike Adamson Engineering +1 650 389 6000 | datastax.com Find DataStax Online: