cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbel...@apache.org
Subject [05/12] git commit: update column_index_size_in_kb description
Date Wed, 16 Jul 2014 21:18:11 GMT
update column_index_size_in_kb description


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/93c27549
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/93c27549
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/93c27549

Branch: refs/heads/trunk
Commit: 93c27549a3b6ad8445bd0ff2c9f5ce3bd9357c2c
Parents: dc7d5a0
Author: Jonathan Ellis <jbellis@apache.org>
Authored: Wed Jul 16 16:17:29 2014 -0500
Committer: Jonathan Ellis <jbellis@apache.org>
Committed: Wed Jul 16 16:17:34 2014 -0500

----------------------------------------------------------------------
 conf/cassandra.yaml | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cassandra/blob/93c27549/conf/cassandra.yaml
----------------------------------------------------------------------
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index f067635..c8064d1 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -421,13 +421,15 @@ auto_snapshot: true
 tombstone_warn_threshold: 1000
 tombstone_failure_threshold: 100000
 
-# Add column indexes to a row after its contents reach this size.
-# Increase if your column values are large, or if you have a very large
-# number of columns.  The competing causes are, Cassandra has to
-# deserialize this much of the row to read a single column, so you want
-# it to be small - at least if you do many partial-row reads - but all
-# the index data is read for each access, so you don't want to generate
-# that wastefully either.
+# Granularity of the collation index of rows within a partition.
+# Increase if your rows are large, or if you have a very large
+# number of rows per partition.  The competing goals are these:
+#   1) a smaller granularity means more index entries are generated
+#      and looking up rows withing the partition by collation column
+#      is faster
+#   2) but, Cassandra will keep the collation index in memory for hot
+#      rows (as part of the key cache), so a larger granularity means
+#      you can cache more hot rows
 column_index_size_in_kb: 64
 
 


Mime
View raw message