[ 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)