Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DCF1618BE0 for ; Mon, 27 Jul 2015 21:10:10 +0000 (UTC) Received: (qmail 59116 invoked by uid 500); 27 Jul 2015 21:10:05 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 59070 invoked by uid 500); 27 Jul 2015 21:10:05 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 58779 invoked by uid 99); 27 Jul 2015 21:10:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jul 2015 21:10:05 +0000 Date: Mon, 27 Jul 2015 21:10:05 +0000 (UTC) From: "Constance Eustace (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-9886) TIMESTAMP - allow USING TIMESTAMP at end of mutation CQL MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-9886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643401#comment-14643401 ] Constance Eustace commented on CASSANDRA-9886: ---------------------------------------------- Ah crap, I was reading 2.0 javadocs. setDefaultTimestamp must have been added in 2.1. I can go that way. > 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 add 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)