cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5649) Move resultset type information into prepare, not execute
Date Tue, 18 Jun 2013 12:31:20 GMT


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:
>             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:

View raw message