[
https://issues.apache.org/jira/browse/CASSANDRA-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504465#comment-13504465
]
Sylvain Lebresne commented on CASSANDRA-4478:
---------------------------------------------
bq. What if instead we make index_interval be CQL3 rows instead of partitions?
I'm not sure I see much benefit of that over measuring it in bytes. Namely:
# that doesn't make tuning easier. What the index_interval represent is how
much of the index file you will need to read at maximum to find the indexed
block you are looking for. So it does fell like to me that having this size in
bytes is *ideal*. In particular, even if CQL3 rows vary less in size than
internal ones, they are still not constant in size depending on the table.
# it will be more complicated/less efficient to implement in practice with the
current code because the index summary is built from the index file. But the
index file doesn't have enough information currently to count cql3 rows.
# a cql3 row count might be fairly meaningless for thrift users.
# currently we still have 2 nested level of indexing, the internal rows and
inside that, the column index. They do are in the same file now, but they are
not merged together. In that situation, I'm not really sure counting cql3 rows
make any sense in fact (of course, we could merge the two level of indexing
together, but that's not a small/simple patch while this ticket is more
straightforward while still putting us in a situation this is probably good
enough for a while).
> Make index_interval be measured in kb (instead of number of keys)
> -----------------------------------------------------------------
>
> Key: CASSANDRA-4478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4478
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.3
>
> Attachments: 4478-incomplete.txt
>
>
> Currently, index_interval is measured in number of keys: how may keys before
> adding an entry to the index summary. After CASSANDRA-2319, each index entry
> also contains the columns index for the row, so index entry can be a bit
> bigger and of differing sizes. Measuring in number of keys is thus
> sub-optimal and difficult to tune, since you might want a different setting
> depending of whether your rows are big or small, but the setting is global.
> So we should move to measuring the interval in bytes.
--
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
