From: Hollow111 <hollow653@gmail.com> To: korablev@tarantool.org Cc: tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH] sql: xfer optimization issue Date: Fri, 20 Apr 2018 15:09:57 +0000 [thread overview] Message-ID: <CAEi+_aoOeCAsdf8QdP2tPqZYRJmzfW=vOBgAtAx2+ZnROMJJZA@mail.gmail.com> (raw) In-Reply-To: <5BB99B27-5F86-4664-AAD5-57A22ECED854@tarantool.org> [-- Attachment #1: Type: text/plain, Size: 4989 bytes --] пт, 20 апр. 2018 г. в 4:02, n.pettik <korablev@tarantool.org>: > > > Currently insertion from the table to another one > > with the same schema using SELECT works wrong. > > The problem lies in xfer optimization which opens cursors for > > all of the indexes and inserts data excessively. > > Now only PRIMARY KEY is used to handle insertion. > > Moreover analyzing xfer optimization I have noticed > > Nitpicking: it is not worth mentioning process of exploration, > just use (in this particular case) statement of facts. > > > diff --git a/src/box/sql/insert.c b/src/box/sql/insert.c > > index ae8dafb..ed134f4 100644 > > --- a/src/box/sql/insert.c > > +++ b/src/box/sql/insert.c > > @@ -1711,6 +1711,7 @@ xferOptimization(Parse * pParse, /* Parser > context */ > > ExprList *pEList; /* The result set of the SELECT */ > > Table *pSrc; /* The table in the FROM clause of SELECT > */ > > Index *pSrcIdx, *pDestIdx; /* Source and destination indices > */ > > + struct index *src_idx, *dest_idx; /* Source and destination > indices */ > > We don’t use forward var declaration: it is obsolete rule from ancient C > standards. > Moreover, we place comments above the code to be commented. > > > + struct space *space; /* Space pointer for pDest and pSrc */ > > The same is here. > > > - assert(destHasUniqueIdx); > > - if ((pDest->iPKey < 0 && pDest->pIndex != 0) /* (1) */ > > - ||destHasUniqueIdx /* (2) */ > > - || (onError != ON_CONFLICT_ACTION_ABORT > > - && onError != ON_CONFLICT_ACTION_ROLLBACK) /* (3) */ > > - ) { > > - /* In some circumstances, we are able to run the xfer > optimization > > - * only if the destination table is initially empty. > > - * This block generates code to make > > - * that determination. > > - * > > - * Conditions under which the destination must be empty: > > - * > > - * (1) There is no INTEGER PRIMARY KEY but there are > indices. > > - * > > - * (2) The destination has a unique index. (The xfer > optimization > > - * is unable to test uniqueness.) > > - * > > - * (3) onError is something other than > ON_CONFLICT_ACTION_ABORT and _ROLLBACK. > > - */ > > - addr1 = sqlite3VdbeAddOp2(v, OP_Rewind, iDest, 0); > > - VdbeCoverage(v); > > - emptyDestTest = sqlite3VdbeAddOp0(v, OP_Goto); > > - sqlite3VdbeJumpHere(v, addr1); > > - } > > Why did you delete if-clause? The code which checks that > table is empty is needed only in the cases in if-clauses, > i.e. in some cases xfer optimisation can be applied even if > table is not initially empty (as far as I understand). > Yes, that's true this code is needed if any of the cases in if-clause != 0. But the point is that in Tarantool there's always a PRIMARY KEY that is obviously unique which means that the second case is always != 0 and the result of the boolean expression is always not 0, hence there's no reason for this if-check. > > + /* The xfer optimization is unable to test uniqueness > > + * while we have a unique PRIMARY KEY in any existing table. > > + * This is the reason we can only run it if the destination table > > Nitpicking: comments should fit into 66 chars. > > > + * is initially empty. > > + * This block generates code to make that determination. > > + */ > > + addr1 = sqlite3VdbeAddOp2(v, OP_Rewind, iDest, 0); > > + VdbeCoverage(v); > > + emptyDestTest = sqlite3VdbeAddOp0(v, OP_Goto); > > + sqlite3VdbeJumpHere(v, addr1); > > + > > + space = space_by_id(SQLITE_PAGENO_TO_SPACEID(pDest->tnum)); > > + dest_idx = space_index(space, 0 /* PK */); > > + space = space_by_id(SQLITE_PAGENO_TO_SPACEID(pSrc->tnum)); > > + src_idx = space_index(space, 0 /* PK */); > > + assert(src_idx); > > + assert(dest_idx); > > We use explicit != NULL checks. > > > + pDestIdx = sqlite3PrimaryKeyIndex(pDest); > > + pSrcIdx = sqlite3PrimaryKeyIndex(pSrc); > > In fact, you don’t need these indexes at all. > Instead of calling emit_open_cursor() you > can simply add two opcodes: OP_LoadPtr and OP_OpenWrite > (as it happens inside that function). Or, you can use pSrc->tnum. > Table’s tnum exactly encodes PK space id (index id is 0). > As for KeyInfo - you are able to remove it at all, since opcodes > below don’t rely on key info (AFAIK, better check it yourself). > The only issue remained - how to check PK compatibility. > I would add to xferCompatibleIndex() another one check: > If first index is PK, then second also must be PK. > It is easy to implement, since Index struct contains appropriate flag. > > [-- Attachment #2: Type: text/html, Size: 6079 bytes --]
next prev parent reply other threads:[~2018-04-20 15:10 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-18 15:32 [tarantool-patches] " N.Tatunov 2018-04-18 16:33 ` [tarantool-patches] " Hollow111 2018-04-19 11:22 ` n.pettik 2018-04-19 15:36 ` Hollow111 2018-04-20 1:02 ` n.pettik 2018-04-20 15:09 ` Hollow111 [this message] 2018-04-20 16:09 ` n.pettik 2018-04-20 17:59 ` Hollow111 2018-04-23 23:40 ` n.pettik 2018-04-27 15:45 ` Hollow111 2018-05-03 22:57 ` n.pettik 2018-05-04 12:54 ` Hollow111 2018-06-28 10:18 ` Alexander Turenko 2018-07-09 15:50 ` Alexander Turenko 2018-07-16 12:54 ` Nikita Tatunov 2018-07-16 13:06 ` n.pettik 2018-07-16 13:20 ` Nikita Tatunov 2018-07-16 18:37 ` Nikita Tatunov 2018-07-16 19:12 ` n.pettik 2018-07-16 21:27 ` Nikita Tatunov 2018-07-18 15:13 ` n.pettik 2018-07-18 20:18 ` Nikita Tatunov 2018-07-19 0:20 ` n.pettik 2018-07-19 17:26 ` Nikita Tatunov 2018-07-20 3:20 ` n.pettik 2018-07-20 11:56 ` Nikita Tatunov 2018-07-20 16:43 ` n.pettik 2018-07-20 16:58 ` Nikita Tatunov 2018-07-29 1:12 ` Alexander Turenko 2018-07-29 11:23 ` n.pettik 2018-07-29 15:16 ` Alexander Turenko 2018-07-30 18:33 ` Nikita Tatunov 2018-07-30 22:17 ` Alexander Turenko 2018-07-31 11:48 ` Nikita Tatunov 2018-07-31 13:29 ` Alexander Turenko 2018-07-31 17:04 ` Nikita Tatunov 2018-07-31 17:44 ` Alexander Turenko 2018-08-21 16:43 ` Kirill Yukhin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAEi+_aoOeCAsdf8QdP2tPqZYRJmzfW=vOBgAtAx2+ZnROMJJZA@mail.gmail.com' \ --to=hollow653@gmail.com \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH] sql: xfer optimization issue' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox