Tarantool development patches archive
 help / color / mirror / Atom feed
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 --]

  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