[ https://issues.apache.org/jira/browse/CASSANDRA-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nitin Padalia updated CASSANDRA-8646: ------------------------------------- Summary: Row Cache Miss with clustering key (was: For Column family ) > Row Cache Miss with clustering key > ---------------------------------- > > Key: CASSANDRA-8646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8646 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OS: CentOS 6.5, [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL > spec 3.2.0 | Native protocol v3]. Using CQL CLI for query analysis. > Reporter: Nitin Padalia > Priority: Minor > Fix For: 2.1.2 > > > Cassandra doesn't hit row cache for first and last row of a partition if we > mention cluster keys in where condition. However if we use limit then it hits > the row cache for the same rows. > E.G. I've a column family: > CREATE TABLE ucxndirdb2.usertable_cache ( > user_id uuid, > dept_id uuid, > location_id text, > locationmap_id uuid, > PRIMARY KEY ((user_id, dept_id), location_id) > ) WITH CLUSTERING ORDER BY (location_id ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = '{"keys":"ALL", "rows_per_partition":"3"}' > AND comment = '' > AND compaction = {'min_threshold': '4', 'class': > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', > 'max_threshold': '32'} > AND compression = {'sstable_compression': > 'org.apache.cassandra.io.compress.LZ4Compressor'} > AND dclocal_read_repair_chance = 0.1 > AND default_time_to_live = 0 > AND gc_grace_seconds = 864000 > AND max_index_interval = 2048 > AND memtable_flush_period_in_ms = 0 > AND min_index_interval = 128 > AND read_repair_chance = 0.0 > AND speculative_retry = '99.0PERCENTILE'; > It has 3 rows per partition keys enabled for row cache. > Now for a cached request, if I run: > select * from usertable_cache WHERE user_id = > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 and dept_id = > de3ac44f-2078-4321-a47c-de96c615d40d limit 3; > Then its a cache hit with follow results: > user_id | dept_id > | location_id | locationmap_id > --------------------------------------+--------------------------------------+-------------+-------------------------------------- > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d > | ABC4:1 | 32b97639-ea5b-427f-8c27-8a5016e2ad6e > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d > | ABC4:10 | dfacc9fc-7a6a-4fb4-8a4f-c13c606d552b > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d > | ABC4:100 | 9ba7236a-6124-41c8-839b-edd299f510f7 > However If I run: > select * from usertable_cache WHERE user_id = > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 and dept_id = > de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:1'; > or > select * from usertable_cache WHERE user_id = > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 and dept_id = > de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:100'; > Then its a cache miss. However for following its hit for following > select * from usertable_cache WHERE user_id = > 7bf16edf-b552-40f4-94ac-87b2e878d8c2 and dept_id = > de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:10'; > and this behavior is consistent by increasing/decreasing rows_per_partiton > setting. Cache is miss for only first and last record of the partition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)