[
https://issues.apache.org/jira/browse/CASSANDRA-9886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Constance Eustace updated CASSANDRA-9886:
-----------------------------------------
Issue Type: New Feature (was: Bug)
> TIMESTAMP - allow USING TIMESTAMP at end of mutation CQL
> ---------------------------------------------------------
>
> Key: CASSANDRA-9886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9886
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Constance Eustace
> Fix For: 2.1.x
>
>
> I was doing performance testing to get off of using batches for our
> persistence engine, and instead use "async spray" with timestamps.
> First of all, it seems fairly insane that the USING TIMESTAMP clause is in a
> different location for INSERT (before WHERE) and the UPDATE (before SET) and
> the DELETE (before WHERE) statements... thus is in the middle of the
> statement for no real apparently good reason, although maybe there is some
> PostGresql compatibility.
> This means that if some code produces a large list of statements without the
> USING TIMESTAMP already in it, because the actual method of execution of a
> list of statements, which may use batches (if we were grouping by partition
> key) or not (single statement) may be determined later...
> Then for single statement updates, the statement needs to properly place the
> USING TIMESTAMP clause. It would be MUCH EASIER to all a simple append of
> "USING TIMESTAMP xxx" at the end of the CQL statement.
> BATCH is easier, you just wrap the statements. Pretty basic.
> I have done performance testing with single-statement BATCH USING TIMESTAMP
> and their performance is awful, worse that "NEVER EVER DO THIS" sync batches
> with cross-partition updates.
> Can we either allow a USING TIMESTAMP to be at the end of all the mutation
> statements in the same place, or have a check in the BATCH statement
> processing to check if its a single statement and reduce it to non-batch
> execution?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
