From: "n.pettik" <korablev@tarantool.org>
To: Hollow111 <hollow653@gmail.com>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH] sql: xfer optimization issue
Date: Fri, 20 Apr 2018 04:02:40 +0300 [thread overview]
Message-ID: <5BB99B27-5F86-4664-AAD5-57A22ECED854@tarantool.org> (raw)
In-Reply-To: <CAEi+_aoTp-jnAtSZXMqo4EACEDS20Rwkvw+yCsH9pKz8X05Y7w@mail.gmail.com>
> 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).
> + /* 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.
next prev parent reply other threads:[~2018-04-20 1:02 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 [this message]
2018-04-20 15:09 ` Hollow111
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=5BB99B27-5F86-4664-AAD5-57A22ECED854@tarantool.org \
--to=korablev@tarantool.org \
--cc=hollow653@gmail.com \
--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