[
https://issues.apache.org/jira/browse/CASSANDRA-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686648#comment-13686648
]
Sylvain Lebresne commented on CASSANDRA-5649:
---------------------------------------------
I have some doubts that this would provide a noticeable benefit in practice.
The type information in the result set is fairly compact (though it's true we
could save the full metadata in practice). I'm not sure reading the message is
much of a bottleneck in practice for small messages (and for big ones, the
metadata size is negligeable anyway). And there is compression too.
On the other side, this does complexify client drivers. Currently, you can
fully decode a result message without any external information. This is a nice
property implementation wise, and is somewhat safer. And I'm not sure requiring
too much state from the client driver to do basic things is ideal.
I can be wrong, but my intuition is that neither MySQL nor PostgreSQL does that
because they don't consider it worth the complexity. And that's my intuition
too.
So I'm fine doing some benchmarking to see if this can make a measurable
difference in practice, but I'm -1 on going ahead with this without concrete
evidence of the benefits since there is known drawbacks. And I kind of feel
it's too late for 2.0.
> 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.0
>
>
> 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
