[
https://issues.apache.org/jira/browse/CASSANDRA-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167630#comment-14167630
]
Aleksey Yeschenko commented on CASSANDRA-7923:
----------------------------------------------
FWIW, there is nothing wrong with the patch itself, it seems. The issue only
affects SelectStatement, too, and indeed has to do with resultset metadata
(which for non-SelectStatement is being set to ResultSet.Metadata.EMPTY).
Seems to be somewhat similar in spirit with CASSANDRA-8054.
> When preparing a statement, do not parse the provided string if we already
> have the parsed statement cached
> -----------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-7923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7923
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Assignee: Aleksey Yeschenko
> Priority: Minor
> Labels: cql, performance
> Fix For: 2.1.1
>
> Attachments: 7923-test.txt, 7923-v2.txt, 7923.txt
>
>
> If there are many clients preparing the same statement (or the same client
> preparing it multiple times), there's no point parsing the statement each
> times. We already have it prepared, we should ship back the prior result.
> I would like us separately to consider introducing some checks to ensure that
> we never have a hash collision (and error if we do, asking the user to salt
> their query string), but this change in no way increases the risk profile
> here, since all we did was overwrite the prior statement with the new one.
> This change means that clients referencing the old statement continue to
> function and the client registering the colliding statement will not execute
> the correct statement, but this is in no way worse than the reverse situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
