[jira] [Updated] (CASSANDRA-5649) Move resultset type information into prepare, not execute

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ 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