[jira] [Commented] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774084#comment-13774084 ] Russell Alexander Spitzer commented on CASSANDRA-6042: -- I've done a preliminary patch for this. I've added a variable to set at what amount of tombstones should start being logged (DEBUG LEVEL). I want to add a JMX handle for changing this on the fly but I'm not sure what a good place for it would be (StorageProxy?) . I've also added a histogram per CF for tracking tombstones in general. My current solution is not ideal as it only can check the last row scanned. This should be sufficient for all queries which specify a row but will miss out on queries which request multiple rows. Also I'd love for some advice on how to write a Unit-test for the JMX interaction. Add WARN when there are a lot of tombstones in a query -- Key: CASSANDRA-6042 URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 Project: Cassandra Issue Type: Improvement Reporter: Jeremiah Jordan Assignee: Russell Alexander Spitzer Priority: Minor Fix For: 1.2.11 Attachments: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Now that we count the number of tombstones hit (so it can go in tracing), can we pick some threshold (or make it configurable with 0 being don't warn), and spit out a warning saying Just went through 1 tombstones in partition XYZ. Right now if you are having GC problems because some row got a bunch of tombstones, you can turn on server side tracing, and hope the bad query gets in there, or you can keep making heap dumps, dig through them, and hope you catch the query in there. I have seen code problems at multiple places causing this same issue (some code causing way more tombstones than it should, for just one row). And it is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Alexander Spitzer updated CASSANDRA-6042: - Attachment: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Add WARN when there are a lot of tombstones in a query -- Key: CASSANDRA-6042 URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 Project: Cassandra Issue Type: Improvement Reporter: Jeremiah Jordan Assignee: Russell Alexander Spitzer Priority: Minor Fix For: 1.2.11 Attachments: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Now that we count the number of tombstones hit (so it can go in tracing), can we pick some threshold (or make it configurable with 0 being don't warn), and spit out a warning saying Just went through 1 tombstones in partition XYZ. Right now if you are having GC problems because some row got a bunch of tombstones, you can turn on server side tracing, and hope the bad query gets in there, or you can keep making heap dumps, dig through them, and hope you catch the query in there. I have seen code problems at multiple places causing this same issue (some code causing way more tombstones than it should, for just one row). And it is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6076) implement HELP COMPOSITE_PRIMARY_KEYS
Dave Brosius created CASSANDRA-6076: --- Summary: implement HELP COMPOSITE_PRIMARY_KEYS Key: CASSANDRA-6076 URL: https://issues.apache.org/jira/browse/CASSANDRA-6076 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.11 HELP COMPOSITE_PRIMARY_KEYS is referenced from HELP CREATE_TABLE, but doesn't exist. added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6076) implement HELP COMPOSITE_PRIMARY_KEYS
[ https://issues.apache.org/jira/browse/CASSANDRA-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-6076: Attachment: 6076.txt implement HELP COMPOSITE_PRIMARY_KEYS -- Key: CASSANDRA-6076 URL: https://issues.apache.org/jira/browse/CASSANDRA-6076 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.11 Attachments: 6076.txt HELP COMPOSITE_PRIMARY_KEYS is referenced from HELP CREATE_TABLE, but doesn't exist. added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774103#comment-13774103 ] Jonathan Ellis commented on CASSANDRA-6042: --- bq. I want to add a JMX handle for changing this on the fly but I'm not sure what a good place for it would be StorageService is our usual catch-all for global settings. bq. My current solution is not ideal as it only can check the last row scanned Well, you've wired it into getColumnFamily which is single-row [partition] anyway. Which is the right thing to do, IMO. So that looks fine to me. bq. I'd love for some advice on how to write a Unit-test for the JMX interaction. Not worth the effort, IMO. :) Nits: - tombstoneDebugAmount - tombstoneDebugThreshold - brace on newline in your instanceof check Rest LGTM. Add WARN when there are a lot of tombstones in a query -- Key: CASSANDRA-6042 URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 Project: Cassandra Issue Type: Improvement Reporter: Jeremiah Jordan Assignee: Russell Alexander Spitzer Priority: Minor Fix For: 1.2.11 Attachments: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Now that we count the number of tombstones hit (so it can go in tracing), can we pick some threshold (or make it configurable with 0 being don't warn), and spit out a warning saying Just went through 1 tombstones in partition XYZ. Right now if you are having GC problems because some row got a bunch of tombstones, you can turn on server side tracing, and hope the bad query gets in there, or you can keep making heap dumps, dig through them, and hope you catch the query in there. I have seen code problems at multiple places causing this same issue (some code causing way more tombstones than it should, for just one row). And it is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Alexander Spitzer updated CASSANDRA-6042: - Attachment: 0002-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Add WARN when there are a lot of tombstones in a query -- Key: CASSANDRA-6042 URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 Project: Cassandra Issue Type: Improvement Reporter: Jeremiah Jordan Assignee: Russell Alexander Spitzer Priority: Minor Fix For: 1.2.11 Attachments: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch, 0002-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Now that we count the number of tombstones hit (so it can go in tracing), can we pick some threshold (or make it configurable with 0 being don't warn), and spit out a warning saying Just went through 1 tombstones in partition XYZ. Right now if you are having GC problems because some row got a bunch of tombstones, you can turn on server side tracing, and hope the bad query gets in there, or you can keep making heap dumps, dig through them, and hope you catch the query in there. I have seen code problems at multiple places causing this same issue (some code causing way more tombstones than it should, for just one row). And it is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774114#comment-13774114 ] Russell Alexander Spitzer commented on CASSANDRA-6042: -- Thanks! I hoped that I had everything in the right place but it is a bit hard to keep the names/read_paths straight in my head. This was a great ticket to start diving into the read path though. Attached revised patch. Add WARN when there are a lot of tombstones in a query -- Key: CASSANDRA-6042 URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 Project: Cassandra Issue Type: Improvement Reporter: Jeremiah Jordan Assignee: Russell Alexander Spitzer Priority: Minor Fix For: 1.2.11 Attachments: 0001-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch, 0002-JMX-and-Debug-Messages-for-Max-Tombstone-Scans.patch Now that we count the number of tombstones hit (so it can go in tracing), can we pick some threshold (or make it configurable with 0 being don't warn), and spit out a warning saying Just went through 1 tombstones in partition XYZ. Right now if you are having GC problems because some row got a bunch of tombstones, you can turn on server side tracing, and hope the bad query gets in there, or you can keep making heap dumps, dig through them, and hope you catch the query in there. I have seen code problems at multiple places causing this same issue (some code causing way more tombstones than it should, for just one row). And it is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6076) implement HELP COMPOSITE_PRIMARY_KEYS
[ https://issues.apache.org/jira/browse/CASSANDRA-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774251#comment-13774251 ] Jonathan Ellis commented on CASSANDRA-6076: --- +1, but can you fix composite - compound wrt primary keys? Compound is the preferred term in SQL, and there is no reason to be gratuitously different. In fact composite is confusing to Thrift users because of CompositeType. (That said, when talking about a *partition* key composed of multiple components, I have no strong preference on composite vs compound -- partly because we've moved away from easy analogies with SQL, and partly because it really is a CompositeType under the hood. OTOH it may be best to leave Composite dead and buried and not burden CQL with extra terminology.) implement HELP COMPOSITE_PRIMARY_KEYS -- Key: CASSANDRA-6076 URL: https://issues.apache.org/jira/browse/CASSANDRA-6076 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.11 Attachments: 6076.txt HELP COMPOSITE_PRIMARY_KEYS is referenced from HELP CREATE_TABLE, but doesn't exist. added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: add help topic COMPOUND_PRIMARY_KEYS for cqlsh patch by dbrosius reviewed by jbellis for cassandra-6076
Updated Branches: refs/heads/cassandra-1.2 fb43309b4 - 7fdcbd0b4 add help topic COMPOUND_PRIMARY_KEYS for cqlsh patch by dbrosius reviewed by jbellis for cassandra-6076 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7fdcbd0b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7fdcbd0b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7fdcbd0b Branch: refs/heads/cassandra-1.2 Commit: 7fdcbd0b433f9c30459f17527a05e5a87eb8efab Parents: fb43309 Author: Dave Brosius dbros...@apache.org Authored: Sun Sep 22 23:44:05 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sun Sep 22 23:44:05 2013 -0400 -- pylib/cqlshlib/helptopics.py | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fdcbd0b/pylib/cqlshlib/helptopics.py -- diff --git a/pylib/cqlshlib/helptopics.py b/pylib/cqlshlib/helptopics.py index cdbb8f4..5130a23 100644 --- a/pylib/cqlshlib/helptopics.py +++ b/pylib/cqlshlib/helptopics.py @@ -226,7 +226,7 @@ class CQLHelpTopics(object): CollatingOrderPreservingPartitioner both require UTF-8 keys. In cql3 mode, a table can have multiple columns composing the primary -key (see HELP COMPOSITE_PRIMARY_KEYS). +key (see HELP COMPOUND_PRIMARY_KEYS). For more information, see one of the following: @@ -235,6 +235,22 @@ class CQLHelpTopics(object): help_create_columnfamily = help_create_table +def help_compound_primary_keys(self): +print +CREATE TABLE cfname ( partition_key type, clustering_key1 type, clustering_key2 type, +[, ...]], PRIMARY KEY (partition_key, clustering_key1, clustering_key2); + +CREATE TABLE allows a primary key composed of multiple columns. When this is the case, specify +the columns that take part in the compound key after all columns have been specified. + +, PRIMARY KEY( key1, key2, ... ) + +The partitioning key itself can be a compound key, in which case the first element of the PRIMARY KEY +phrase should be parenthesized, as + +PRIMARY KEY ((partition_key_part1, partition_key_part2), clustering_key) + + def help_create_table_types(self): print CREATE TABLE: Specifying column types
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/05952e7c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/05952e7c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/05952e7c Branch: refs/heads/cassandra-2.0 Commit: 05952e7c6e72d971eed1d447f7ff23c5daf361e3 Parents: 7ce28f8 7fdcbd0 Author: Dave Brosius dbros...@apache.org Authored: Sun Sep 22 23:47:59 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sun Sep 22 23:47:59 2013 -0400 -- pylib/cqlshlib/helptopics.py | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/05952e7c/pylib/cqlshlib/helptopics.py --
[1/3] git commit: add help topic COMPOUND_PRIMARY_KEYS for cqlsh patch by dbrosius reviewed by jbellis for cassandra-6076
Updated Branches: refs/heads/trunk fe4606ce1 - 494cc32d2 add help topic COMPOUND_PRIMARY_KEYS for cqlsh patch by dbrosius reviewed by jbellis for cassandra-6076 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7fdcbd0b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7fdcbd0b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7fdcbd0b Branch: refs/heads/trunk Commit: 7fdcbd0b433f9c30459f17527a05e5a87eb8efab Parents: fb43309 Author: Dave Brosius dbros...@apache.org Authored: Sun Sep 22 23:44:05 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sun Sep 22 23:44:05 2013 -0400 -- pylib/cqlshlib/helptopics.py | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fdcbd0b/pylib/cqlshlib/helptopics.py -- diff --git a/pylib/cqlshlib/helptopics.py b/pylib/cqlshlib/helptopics.py index cdbb8f4..5130a23 100644 --- a/pylib/cqlshlib/helptopics.py +++ b/pylib/cqlshlib/helptopics.py @@ -226,7 +226,7 @@ class CQLHelpTopics(object): CollatingOrderPreservingPartitioner both require UTF-8 keys. In cql3 mode, a table can have multiple columns composing the primary -key (see HELP COMPOSITE_PRIMARY_KEYS). +key (see HELP COMPOUND_PRIMARY_KEYS). For more information, see one of the following: @@ -235,6 +235,22 @@ class CQLHelpTopics(object): help_create_columnfamily = help_create_table +def help_compound_primary_keys(self): +print +CREATE TABLE cfname ( partition_key type, clustering_key1 type, clustering_key2 type, +[, ...]], PRIMARY KEY (partition_key, clustering_key1, clustering_key2); + +CREATE TABLE allows a primary key composed of multiple columns. When this is the case, specify +the columns that take part in the compound key after all columns have been specified. + +, PRIMARY KEY( key1, key2, ... ) + +The partitioning key itself can be a compound key, in which case the first element of the PRIMARY KEY +phrase should be parenthesized, as + +PRIMARY KEY ((partition_key_part1, partition_key_part2), clustering_key) + + def help_create_table_types(self): print CREATE TABLE: Specifying column types
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/494cc32d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/494cc32d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/494cc32d Branch: refs/heads/trunk Commit: 494cc32d26fcbda0842bc0159c169f72116bbc46 Parents: fe4606c 05952e7 Author: Dave Brosius dbros...@apache.org Authored: Sun Sep 22 23:48:32 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sun Sep 22 23:48:32 2013 -0400 -- pylib/cqlshlib/helptopics.py | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) --
[jira] [Resolved] (CASSANDRA-6076) implement HELP COMPOSITE_PRIMARY_KEYS
[ https://issues.apache.org/jira/browse/CASSANDRA-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius resolved CASSANDRA-6076. - Resolution: Fixed Reviewer: jbellis switch verbage to COMPOUND and committed to cassandra-1.2 as 7fdcbd0b433f9c30459f17527a05e5a87eb8efab implement HELP COMPOSITE_PRIMARY_KEYS -- Key: CASSANDRA-6076 URL: https://issues.apache.org/jira/browse/CASSANDRA-6076 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.11 Attachments: 6076.txt HELP COMPOSITE_PRIMARY_KEYS is referenced from HELP CREATE_TABLE, but doesn't exist. added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5357) Query cache
[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774291#comment-13774291
]
Vijay commented on CASSANDRA-5357:
--
Hi Jonathan, I have pushed a version with sentinel (might have made it little
hackie, but it works)
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.
{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for
example there can be a named query for Column A, Z which can be followed by a
slice query from A to Z and we might not respond with the right response since
B to Y is not in the cache.
In a separate ticket we can also optimize the above case (and more) cache
query's stored, if thats ok. Example: If the slice with 250 is stored why to
also store the slice with 50 in the same range, we can also merge overlapping
slices etc.
{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by
implementing a Iterator which will be similar to SSTableIterator to stream the
columns than constructing the ColumnFamily at once.
Thanks!
Query cache
---
Key: CASSANDRA-5357
URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Vijay
I think that most people expect the row cache to act like a query cache,
because that's a reasonable model. Caching the entire partition is, in
retrospect, not really reasonable, so it's not surprising that it catches
people off guard, especially given the confusion we've inflicted on ourselves
as to what a row constitutes.
I propose replacing it with a true query cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5357) Query cache
[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774291#comment-13774291
]
Vijay edited comment on CASSANDRA-5357 at 9/23/13 4:48 AM:
---
Hi Jonathan, I have pushed a version with sentinel (might have made it little
hackie, but it works)
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.
{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for
example there can be a named query for Column A, Z which can be followed by a
slice query from A to Z and we might not respond with the right response since
B to Y is not in the cache.
In a separate ticket we can also optimize the above case (and more) cache
query's stored, if thats ok. Example: If the slice with count as 250 is stored
we might not need to store the slice with count of 50 with same range, we can
also merge overlapping slices etc.
{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by
implementing a Iterator which will be similar to SSTableIterator to stream the
columns than constructing the ColumnFamily at once.
Thanks!
was (Author: vijay2...@yahoo.com):
Hi Jonathan, I have pushed a version with sentinel (might have made it
little hackie, but it works)
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.
{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for
example there can be a named query for Column A, Z which can be followed by a
slice query from A to Z and we might not respond with the right response since
B to Y is not in the cache.
In a separate ticket we can also optimize the above case (and more) cache
query's stored, if thats ok. Example: If the slice with 250 is stored why to
also store the slice with 50 in the same range, we can also merge overlapping
slices etc.
{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by
implementing a Iterator which will be similar to SSTableIterator to stream the
columns than constructing the ColumnFamily at once.
Thanks!
Query cache
---
Key: CASSANDRA-5357
URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Vijay
I think that most people expect the row cache to act like a query cache,
because that's a reasonable model. Caching the entire partition is, in
retrospect, not really reasonable, so it's not surprising that it catches
people off guard, especially given the confusion we've inflicted on ourselves
as to what a row constitutes.
I propose replacing it with a true query cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
