cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10309) Avoid always looking up column type
Date Sun, 13 Sep 2015 09:57:46 GMT

    [ 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)

Mime
View raw message