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 0F8C52714E for ; Sat, 28 Jul 2018 21:12:55 -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 fADaXNyJyXA4 for ; Sat, 28 Jul 2018 21:12:54 -0400 (EDT) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 3F73A26235 for ; Sat, 28 Jul 2018 21:12:54 -0400 (EDT) Date: Sun, 29 Jul 2018 04:12:51 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH] sql: xfer optimization issue Message-ID: <20180729011251.eitp7cisv6jv5opj@tkn_work_nb> References: <8B8D5501-075D-4BEB-B282-35B0B81CD555@tarantool.org> <605B15EF-BD1C-4B03-8A9F-6E6225076812@tarantool.org> <12B62C73-9BEC-49FA-B3FD-590C445CF25B@tarantool.org> <2123605D-8D6C-43A3-846F-735E4C2C7FC2@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: Nikita Tatunov Cc: tarantool-patches@freelists.org Hi! Please consider my comments and questions below. WBR, Alexander Turenko. > + /* > + * Xfer optimization is unable to correctly insert data > + * in case there's a conflict action other than > + * explicit *_ABORT. This is the reason we want to only > + * run it if the destination table is initially empty. > + * That block generates code to make that determination. > + */ > + if (!(onError == ON_CONFLICT_ACTION_ABORT && > + !is_err_action_default)) { Do you mean that: 1. The optimization non-empty table case correctly works only with ABORT conflict action (default or explicit). 2. The default conflict action can be overwritten on per-column basis, so 'default abort' can really be replace or other conflict action. If so, your description doesn't give this information. To more on that, can we check per-column conflict actions instead of check whether the conflict action default or explicit? This would enable more cases with non-empty tables for the optimization. And this would look less confusing, IMHO. I have one more question on that. It seems that SQLite has this optimization working with ROLLBACK conflict action. We cannot doing so, because of some problem? Did this problem described / trackerized somewhere? Or something changes underhood and makes this impossible? Are we know exact reason or just observing it does not work? > +#ifdef SQLITE_TEST > +/* > + * The following global variable is incremented whenever the > + * transfer optimization is used. This is used for testing > + * purposes only - to make sure the transfer optimization really > + * is happening when it is supposed to. > + */ > +int sql_xfer_count = 0; > +#endif I think it would be good to mention the opcode where the counter is incremented. You can follow the style in which other counters are described (they are mostly mention opcodes). > -/* Opcode: RowData P1 P2 * * * > +/* Opcode: RowData P1 P2 * * P5 We can increase the counter on per-operation basis instead of per-row by adding the flag to OP_OpenWrite. It will save some CPU cycles :) > +#ifdef SQLITE_TEST > + if ((pOp->p5 & OPFLAG_XFER_OPT) != 0) { > + pOp->p5 = 0; > + sql_xfer_count++; > + } > +#endif 1. Not actual due to 2, but it would be better to use `pOp->p5 &= ~OPFLAG_XFER_OPT` to drop just that flag. 2. It is counter-intuitive, IMHO, to change operation flags during that operation. So, said above, vote to move it to OP_OpenWrite. > +local bfr, aftr > + What do you plan to do with saved letters? :) Really, such abbreviations just makes reading harder with no gains. > +local function do_xfer_test(test_number, return_code) > + test_name = string.format("xfer-optimization-1.%d", test_number) > + test:do_test( > + test_name, > + function() > + return {aftr - bfr} > + end, { > + -- > + return_code > + -- > + }) > +end That code can be written simpler (consider tap module documentation): test:is(after - before, exp, test_name) I suggest to create wrappers like so (I didn't test it): local function do_xfer_test(test_func, test, test_name, func, exp, opts) local opts = opts or {} local exp_xfer_count = opts.exp_xfer_count local before = box.sql.debug().sql_xfer_count local ok = test_func(test, test_name, func, exp) local after = box.sql.debug().sql_xfer_count if exp_xfer_count ~= nil then ok = ok and test:is(after - before, exp_xfer_count, test_name .. '_xfer_count') end return ok end test.do_execsql_xfer_test = function(test, test_name, func, exp, opts) return do_xfer_test(test.do_execsql_test, test, test_name, func, exp, opts) end test.do_catchsql_xfer_test = function(test, test_name, func, exp, opts) return do_xfer_test(test.do_catchsql_test, test, test_name, func, exp, opts) end And use it like so: test:do_catchsql_xfer_test( "xfer-optimization-1.1", [[ CREATE TABLE t1(a INTEGER PRIMARY KEY, b INTEGER UNIQUE); INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3); CREATE TABLE t2(a INTEGER PRIMARY KEY, b INTEGER UNIQUE); INSERT INTO t2 SELECT * FROM t1; ]], { -- 0 -- }), { exp_xfer_count = 1 } ) By the way, you can revive xfer cases in test/sql-tap/with2.test.lua. Or drop it if your new test includes all related cases from with2. On Fri, Jul 20, 2018 at 07:58:48PM +0300, Nikita Tatunov wrote: > Ooops. Thank you! fixed it and pushed. > > пт, 20 июл. 2018 г. в 19:43, n.pettik <[1]korablev@tarantool.org>: > > LGTM. > > diff --git a/src/box/sql/insert.c b/src/box/sql/insert.c > index 3c3bf37..4f52fa5 100644 > --- a/src/box/sql/insert.c > +++ b/src/box/sql/insert.c > @@ -1869,7 +1869,7 @@ xferOptimization(Parse * pParse, /* Parser > context */ > * table (tab1) is initially empty. > */ > > - /* The Vdbe we're building*/ > + /* The Vdbe struct we're building. */ > > You misunderstood me. What I mean is: > struct Vibe *v = …; > > Vdbe *v = sqlite3GetVdbe(pParse); > > References > > 1. mailto:korablev@tarantool.org