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 ED63521CB0 for ; Mon, 9 Jul 2018 11:50:06 -0400 (EDT) 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 x-8UGVuqlsvk for ; Mon, 9 Jul 2018 11:50:06 -0400 (EDT) Received: from smtp51.i.mail.ru (smtp51.i.mail.ru [94.100.177.111]) (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 A936521AC1 for ; Mon, 9 Jul 2018 11:50:06 -0400 (EDT) Date: Mon, 9 Jul 2018 18:50:07 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH] sql: xfer optimization issue Message-ID: <20180709155006.fwrikbznqk23ger5@tkn_work_nb> References: <5BB99B27-5F86-4664-AAD5-57A22ECED854@tarantool.org> <93E4DAEA-EF90-479D-9F62-3D1CEB3CBE3F@tarantool.org> <20180628101839.fhnijezdpwviohop@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180628101839.fhnijezdpwviohop@tkn_work_nb> 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: Nikita Tatunov Cc: tarantool-patches@freelists.org, Nikita Pettik , Kirill Yukhin Hi Nikita! Please, consider comments below. WBR, Alexander Turenko. > +test:do_execsql_test( > + "xfer-oprimization-1.8", > ... > +test:do_execsql_test( > + "xfer-oprimization-1.10", > ... > +test:do_execsql_test( > + "xfer-oprimization-1.12", > ... > +test:do_execsql_test( > + "xfer-oprimization-1.16", > +test:do_execsql_test( > + "xfer-oprimization-1.18", oprimization -> optimization It seems that review questions from the last Nikita email in the thread was not fixed or answered (at least some of them). > + sqlite3VdbeAddOp3(v, OP_OpenWrite, iSrc, > + pSrc->tnum, space_ptr_reg); Why do you open source space for write? How your changes to xferCompatibleIndex and empty check enabling condition is motivated? It is hard to understand it without more detailed description. --- EOF. On Thu, Jun 28, 2018 at 01:18:39PM +0300, Alexander Turenko wrote: > On Fri, May 04, 2018 at 12:54:30PM +0000, Hollow111 wrote: > > > @@ -1737,8 +1744,10 @@ xferOptimization(Parse * pParse, /* > > Parser context */ > > > if (onError == ON_CONFLICT_ACTION_DEFAULT) { > > > if (pDest->iPKey >= 0) > > > onError = pDest->keyConf; > > > - if (onError == ON_CONFLICT_ACTION_DEFAULT) > > > + if (onError == ON_CONFLICT_ACTION_DEFAULT) { > > > onError = ON_CONFLICT_ACTION_ABORT; > > > + confl_action_default = 1; > > Why do you need this variable at all? I mean, DEFAULT always > > is an alias to ABORT, isn’t it? > > Yes, it is, but there's a little difference between directly specified > > ABORT for an > > insert stmt (INSERT OR ABORT) and just INSERT without any specified > > error action > > (ABORT specified by the internals). When you directly specify it ABORT > > is a higher priority > > action than in case there's a column with REPLACE error action. Thus we > > can even insert > > not in the empty destination table. > > If an user asks for ABORT explicitly we should make abort, I think. > > As I understood the extra variable appears due to the fact than we can > have per-column conflict clauses in CREATE TABLE and per-table clause > with INSERT OR ABORT. The latter should have precedence, I think. > > I don't sure whether something (behaviour? code?) should be different > from SQLite here in light of #2963 changes. Kirill, Nikita, can you > comment, please? > > WBR, Alexander Turenko. >