[
https://issues.apache.org/jira/browse/CASSANDRA-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742430#comment-14742430
]
Benedict commented on CASSANDRA-10309:
--------------------------------------
It's not the schema metadata we're looking it up in, but the type stored
against the sstable. There are definitely more performant ways of doing this,
though.
* For instance, we could set the map to null if in
{{SerializationHeader.Component.toHeader}} if all of the types match
* We could construct a special {{ColumnDefinition}} type, that contains the
type we read from the sstable, but also stores the "real" {{ColumnDefinition}}
as a field; in {{BufferCell.deserialize}} we could then {{instanceof}} check if
we're one of these, and unwrap the {{ColumnDefinition}} to pass to our
constructor.
Although I must admit I'm not super familiar with how we handle type changes.
It looks like we permit type changes that have different representations, but
don't make any attempt to convert the type....
> Avoid always looking up column type
> -----------------------------------
>
> Key: CASSANDRA-10309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10309
> Project: Cassandra
> Issue Type: Bug
> Reporter: T Jake Luciani
> Priority: Minor
> 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)
