[
https://issues.apache.org/jira/browse/CASSANDRA-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146056#comment-13146056
]
Jonathan Ellis commented on CASSANDRA-3469:
-------------------------------------------
I'm picturing something like
{code}
class RequestStats {
EstimatedHistogram latency, sstablesRead, columnCount, rowCount
}
Map<QueryIdentifier, RequestStats> stats;
{code}
The QueryIdentifier piece will be the interesting part!
This is starting to feel relatively heavyweight, so we might need to add the
ability to enable/disable stat tracking via JMX. Or maybe we allow tracking a
fraction from 0 to 1, as with ReadRepairChance. Of course we should benchmark
before assuming this is the case.
> More fine-grained request statistics
> ------------------------------------
>
> Key: CASSANDRA-3469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3469
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Yuki Morishita
> Priority: Minor
> Fix For: 1.1
>
>
> It would be useful to split the CFS stats up by query type. slice vs named
> vs range vs index, to start with (right now we don't track range scans at
> all), but also at the "prepared statement" level as it were:
> {{SELECT x FROM foo WHERE key = ?}} would be one query no matter what the ?
> is, but {{SELECT y FROM foo WHERE key = ?}} would be different. {{SELECT
> x..y FROM foo WHERE key = ?}} would be another, as would {{SELECT x FROM foo
> WHERE key = ? AND bar= ?}}. (But {{SELECT x FROM foo WHERE bar = ? AND key =
> ?}} would be identical to the former, of course.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
