[
https://issues.apache.org/jira/browse/CASSANDRA-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743616#comment-14743616
]
Benedict commented on CASSANDRA-10309:
--------------------------------------
It might be cheaper/cleaner to modify the subset (de)serialization to support
simply a btree being provided (rather than a Columns), and to maintain a btree
of objects with this information.
It's probably not a big deal; otherwise to do it affordably we can explicitly
enumerate a BTreeSearchIterator.
bq. (or the reverse)
This is not currently handled; if we expect this to be OK (and we do permit
this for {{SimpleDateType}}) we need to change cell serilalization to
pad/truncate any value, or we need to perform some kind of conversion
ourselves. We need to do this for memtables as well, or (perhaps more safely)
we need to ensure any alter table is executed exactly on a memtable flush
boundary.
> Avoid always looking up column type
> -----------------------------------
>
> Key: CASSANDRA-10309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10309
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Priority: Minor
> Labels: perfomance
> Fix For: 3.x
>
>
> Doing some read profiling I noticed we always seem to look up the type of a
> column from the schema metadata when we have the type already in the column
> class.
> This one simple change to SerializationHeader improves read performance
> non-trivially.
> https://github.com/tjake/cassandra/commit/69b94c389b3f36aa035ac4619fd22d1f62ea80b2
> http://cstar.datastax.com/graph?stats=3fb1ced4-58c7-11e5-9faf-42010af0688f&metric=op_rate&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=357.94&ymin=0&ymax=157416.6
> I assume we are looking this up to deal with schema changes. But I'm sure
> there is a more performant way of doing this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
