From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DF80F22CD3 for ; Thu, 10 Jan 2019 07:30:54 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k5QHlQZFDYG for ; Thu, 10 Jan 2019 07:30:54 -0500 (EST) Received: from smtp54.i.mail.ru (smtp54.i.mail.ru [217.69.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 4A96022C4A for ; Thu, 10 Jan 2019 07:30:54 -0500 (EST) Date: Thu, 10 Jan 2019 15:30:51 +0300 From: Kirill Yukhin Subject: [tarantool-patches] Re: [PATCH v2 0/5] sql: do not use OP_Delete+OP_Insert for UPDATES Message-ID: <20190110123051.j6j54d5kvlybmays@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: korablev@tarantool.org, Kirill Shcherbatov Hello, On 29 Dec 13:48, Kirill Shcherbatov wrote: > Introduced a new OP_Update opcode making Tarantool native Update > operation. > In case of UPDATE or REPLACE we can't use new OP_Update as it > has a complex SQL-specific semantics: > > CREATE TABLE tj (s1 INT PRIMARY KEY, s2 INT); > INSERT INTO tj VALUES (1, 3),(2, 4),(3,5); > CREATE UNIQUE INDEX i ON tj (s2); > SELECT * FROM tj; > [1, 3], [2, 4], [3, 5] > UPDATE OR REPLACE tj SET s2 = s2 + 1; > SELECT * FROM tj; > [1, 4], [3, 6] > > I.e. [1, 3] tuple is updated as [1, 4] and have replaced tuple > [2, 4]. This logic is implemented as preventive tuples deletion > by all corresponding indexes in SQL. > > The other significant change is forbidden primary key update. > It was possible to deal with it the same way like with or > REPLACE specifier but we need an atomic UPDATE step for #3691 > ticket to support "or IGNORE/or ABORT/or FAIL" specifiers. > Reworked tests to make testing avoiding primary key UPDATE where > possible. > > Fixed bug in VDBE - sometimes temporal tuples in memory allocated > with sql_vdbe_mem_alloc_region were stored in Mem variable having > invalid flags set. > > Changes in version 2: > - Reworked part of code to close tikets #3035, #3918: reused > a new routine mpstream_encode_vdbe_mem to encode tuples on > region everywhere on Vdbe execution: got rid of routines > sqlite3VdbeMsgpackRecordLen and sqlite3VdbeMsgpackRecordPut > that became useless. > - Fixed few spell mistakes in comments and commit messages > - Minor code changes: better mpstream methods names, changed > OP_IdxUpdate to OP_Update name. > > Branch: http://github.com/tarantool/tarantool/tree/kshch/gh-3850-op-update > Issue: https://github.com/tarantool/tarantool/issues/3850 I've checked your patch set into 2.1 branch. -- Regards, Kirill Yukhin