[
https://issues.apache.org/jira/browse/CASSANDRA-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498236#comment-14498236
]
Sylvain Lebresne commented on CASSANDRA-8437:
---------------------------------------------
What I'm saying is that with {{IN}}, a single call to {{SP.fetchRows}} ends up
doing more than one internal query. What we expose currently is 1) the number
of calls to {{SP.fetchRows}} and 2) the total number of mismatches, which you
can have more than one per call to {{SP.fetchRows}}. And so those shouldn't be
compared. That still left 2 possibilities:
# compare the number of calls to {{SP.fetchRows}} to the number of time at
least one mismatch happens during such call. That's what the current patch does.
# compare the number of internal queries with the number of total mismatches.
Both are valid solution, but I feel that's 2) is a bit more natural. And If
I've suggested 1) before, I've just changed my mind.
> Track digest mismatch ratio
> ---------------------------
>
> Key: CASSANDRA-8437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Benjamin Lerer
> Priority: Minor
> Fix For: 2.1.5
>
> Attachments: CASSANDRA-8437-V2.txt, CASSANDRA-8437.txt
>
>
> I don't believe we track how often read results in a digest mismatch but we
> should since that could directly impact read performance in practice.
> Once we have that data, it might be that some workloads (write heavy most
> likely) ends up with enough mismatches that going to the data read is more
> efficient in practice. What we do about it it step 2 however, but getting the
> data is easy enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
