[
https://issues.apache.org/jira/browse/CASSANDRA-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5649:
--
Fix Version/s: (was: 2.0)
2.1
This doesn't look negligible at all to me. Here's the metadata encode:
{code}
public ChannelBuffer encode(Metadata m)
{
boolean globalTablesSpec =
m.flags.contains(Flag.GLOBAL_TABLES_SPEC);
int stringCount = globalTablesSpec ? 2 + m.names.size() : 3*
m.names.size();
CBUtil.BufferBuilder builder = new CBUtil.BufferBuilder(1 +
m.names.size(), stringCount, 0);
ChannelBuffer header = ChannelBuffers.buffer(8);
header.writeInt(Flag.serialize(m.flags));
header.writeInt(m.names.size());
builder.add(header);
if (globalTablesSpec)
{
builder.addString(m.names.get(0).ksName);
builder.addString(m.names.get(0).cfName);
}
for (ColumnSpecification name : m.names)
{
if (!globalTablesSpec)
{
builder.addString(name.ksName);
builder.addString(name.cfName);
}
builder.addString(name.toString());
builder.add(DataType.codec.encodeOne(DataType.fromType(name.type)));
}
return builder.build();
}
{code}
Here's the (per-row) ResultSet encode:
{code}
for (ByteBuffer bb : row)
builder.addValue(bb);
{code}
Hmm. :)
Seriously, it's trivial to see how you will more often than not have more
metadata than row data for typical single-row resultsets. I can put together a
wrapper to prove it but it's kind of a waste of time.
You're right that it's not reasonable to try for 2.0, though. Moved to 2.1.
> Move resultset type information into prepare, not execute
> -
>
> Key: CASSANDRA-5649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5649
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 2.1
>
>
> Native protocol 1.0 sends type information on execute. This is a minor
> inefficiency for large resultsets; unfortunately, single-row resultsets are
> common.
> This does represent a performance regression from Thrift; Thrift does not
> send type information at all. (Bad for driver complexity, but good for
> performance.)
--
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
