-----It’s probably just a logging / visibility problem, but we should confirm
I think it is. Cause with tracing on, cqlsh logs that "read 1 live rows... " for the query with both clustering key restricted but the whole partition (with no clustering key restriction) has 12 live rows, so i suppose that clustering key restrictions been pushed down to storage engine. Thanks Jeff Sent using https://www.zoho.com/mail/ ---- On Mon, 13 Jan 2020 08:38:44 +0330 onmstester onmstester <mailto:onmstes...@zoho.com.INVALID> wrote ---- Done. https://issues.apache.org/jira/browse/CASSANDRA-15500 Sent using https://www.zoho.com/mail/ ---- On Sun, 12 Jan 2020 19:22:33 +0330 Jeff Jirsa <mailto:jji...@gmail.com> wrote ---- Can you open a jira so someone can investigate ? It’s probably just a logging / visibility problem, but we should confirm Sent from my iPhone On Jan 12, 2020, at 6:04 AM, onmstester onmstester <mailto:onmstes...@zoho.com.invalid> wrote: Using Apache Cassandra 3.11.2, defined a table like this: create table my_table( partition text, clustering1 int, clustering2 text, data set<text>, primary key (partition, clustering1, clustering2)) and configured slow queries threshold to 1ms in yaml to see how queries passed to cassandra. Query below: select * from my_table where partition='a' and clustering1= 1 and clustering2='b' would be like this in debug.log of cassandra: select * from my_table where partition='a' LIMIT 100> (it means that the two cluster key restriction did not push down to storage engine and the whole partition been retrieved) but this query: select * from my_table where partition='a' and clustering1= 1 would be select * from my_table where partition='a' and clustering1= 1 LIMIT 100> (single cluster key been pushed down to storage engine) So it seems to me that, we could not restrict multiple clustering keys in select because it would retrieve the whole partition ?! Sent using https://www.zoho.com/mail/
