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
