Caleb Rackliffe created CASSANDRA-18896: -------------------------------------------
Summary: ClientRequestSize metrics should not treat CONTAINS restrictions as being equality-based Key: CASSANDRA-18896 URL: https://issues.apache.org/jira/browse/CASSANDRA-18896 Project: Cassandra Issue Type: Improvement Components: Observability/Metrics Reporter: Caleb Rackliffe Assignee: Caleb Rackliffe The following behavior needs to be changed to consider the column restricted by {{CONTAINS}} or {{CONTAINS KEY}} as "read", rather than "provided by the client". We already do this for things like range restrictions, and the current behavior is inconsistent. {noformat} @Test public void shouldRecordReadMetricsForContainsQuery() throws Throwable { createTable("CREATE TABLE %s (pk int, ck int, v set<int>, PRIMARY KEY (pk, ck))"); executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (1, 1, {1, 2, 3} )"); executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (2, 2, {4, 5, 6})"); executeNet(CURRENT, "SELECT * FROM %s WHERE v CONTAINS 1 ALLOW FILTERING"); assertEquals(1, ClientRequestSizeMetrics.totalRowsRead.getCount()); // The filtering term is provided by the client in the request, so we don't consider that column read. assertEquals(2, ClientRequestSizeMetrics.totalColumnsRead.getCount()); } {noformat} The fix should be literally two lines, one in {{SingleRestriction}} and one in the test above. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org