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 282242E301 for ; Tue, 14 May 2019 14:22:54 -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 aBgl37khhneY for ; Tue, 14 May 2019 14:22:54 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 9038F2E2F4 for ; Tue, 14 May 2019 14:22:53 -0400 (EDT) From: "n.pettik" Message-Id: <60C9520B-20B2-4944-B44E-99B6A3E454EB@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_BC5DAC86-4D1A-4A42-81A9-712528AEA967" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: [tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces Date: Tue, 14 May 2019 21:22:50 +0300 In-Reply-To: References: <20190514170050.GB5201@atlas> 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: tarantool-patches@freelists.org Cc: Konstantin Osipov , Kirill Shcherbatov --Apple-Mail=_BC5DAC86-4D1A-4A42-81A9-712528AEA967 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> On 14 May 2019, at 20:00, Konstantin Osipov = wrote: >>=20 >> * Kirill Shcherbatov [19/05/14 18:04]: >>> @v.shpilevoy >>>> Yes, I will. Kirill, please, send it again in a new thread. You can = keep >>>> version 3 and omit change list. >>>=20 >>> @kostya >>>> It's better to fetch the bound field upon first access. >>>> Most paths of the CHECK constraint may not touch most of the >>>> fields. >>> I have no idea, how, to fit it in our architecture. >>> OP_Column has no intersections with binding machinery. >>=20 >> Well, I agree something like OP_fetch is necessary. We can=E2=80=99t we simply do this: Add to ck_constraint array of used field numbers - that=E2=80=99s done during ck_constraint_program_compile() while we have struct Expr by traversing AST. Then, we emit OP_Variable ck_field_count times, where ck_field_count is length of array of used field numbers. Part of code responsible for CK code generation is: case TK_COLUMN:{ int iTab =3D pExpr->iTable; int col =3D pExpr->iColumn; if (iTab < 0) { if (pParse->ckBase > 0) { /* Generating CHECK constraints. */ return col + pParse->ckBase; } So we have to pass that array to parsing context. Using that array code will look like this: =E2=80=A6 for (int i =3D 0; i < ck_field_count; ++i) { if (ck_fields[i] =3D=3D col) return ck_fields[i]; } assert(0); When it=E2=80=99s time to run program, we go through array and assign only fields present there: =E2=80=A6 for (int i =3D 0; i < ck_field_count; ++i) { sql_bind_decode(&bind, ck_fields[i]) sql_bind_column(...) } >>> Fire CK constraints for LUA spaces. >>> To achieve this goal, we reworked data dictionary, to store ck >>> constraints in separate space _ck_constraints and updated data >>> migration script to migrate existent data there. This also would >>> be useful in future to implement ALTER SPACE ADD CONSTRAINT >>> operation. Now we do not support CK constraint creation on >>> non-empty space. >>=20 >> Is there a ticket for adding CHECK constraint on a non-empty >> space? >>=20 >> We need to add a general do-any-alter-by-rebuild algorithm so that >> all such features work by rebuilding a table. We could optimize >> these later. >>=20 >> *No* SQL feature is usable unless DDL related to this feature >> works on a non-empty space, at least somehow. >>=20 >>> Each CK has own precompiled VDBE machine that performs this >>> check with tuple fields mapped to it's memory with sql_bind() api. >>=20 >> Good. >>=20 >>=20 >> --=20 >> Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 --Apple-Mail=_BC5DAC86-4D1A-4A42-81A9-712528AEA967 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 = May 2019, at 20:00, Konstantin Osipov <kostja@tarantool.org> wrote:

* Kirill Shcherbatov <kshcherbatov@tarantool.org> [19/05/14 18:04]:
@v.shpilevoy
Yes, I will. Kirill, = please, send it again in a new thread. You can keep
version = 3 and omit change list.

@kostya
It's= better to fetch the bound field upon first access.
Most = paths of the CHECK constraint may not touch most of the
fields.
I have no idea, how, to = fit it in our architecture.
OP_Column has no intersections = with binding machinery.

Well, = I agree something like OP_fetch is = necessary.

We can=E2=80=99= t we simply do this:

Add to ck_constraint array of used field numbers -
that=E2=80=99s done during = ck_constraint_program_compile()
while we have struct Expr by traversing AST. Then,
we emit OP_Variable = ck_field_count times, where
ck_field_count is length of array of used field = numbers.

Part of code = responsible for CK code generation is:

case TK_COLUMN:{
          &nb= sp;  int iTab =3D pExpr->iTable;
          &nb= sp;  int col =3D pExpr->iColumn;
          &nb= sp;  if (iTab < 0) {
          &nb= sp;         if = (pParse->ckBase > 0) {
          &nb= sp;            = ;    /* Generating CHECK constraints. */
          &nb= sp;            = ;    return col + pParse->ckBase;
          &nb= sp;         }


So we have to pass that array to = parsing context.
Using that array code will look like this:

=E2=80=A6
for (int i =3D 0; i < = ck_field_count; ++i) {
= if = (ck_fields[i] =3D=3D col)
= return = ck_fields[i];
}
assert(0);

When it=E2=80=99s time to run = program, we go through array
and assign only fields present there:

=E2=80=A6
for (int i =3D 0; i < = ck_field_count; ++i) {
= sql_bind_decode(&bind, ck_fields[i])
sql_bind_column(...)
}

Fire CK constraints for = LUA spaces.
To achieve this goal, we reworked data = dictionary, to store ck
constraints in separate space = _ck_constraints and updated data
migration script to = migrate existent data there. This also would
be useful in = future to implement ALTER SPACE ADD CONSTRAINT
operation. = Now we do not support CK constraint creation on
non-empty = space.

Is there a ticket for = adding CHECK constraint on a non-empty
space?

We need to add a general = do-any-alter-by-rebuild algorithm so that
all such = features work by rebuilding a table. We could optimize
these= later.

*No* SQL feature is usable unless = DDL related to this feature
works on a non-empty space, at = least somehow.

Each CK has own precompiled VDBE machine that performs = this
check with tuple fields mapped to it's memory with = sql_bind() api.

Good.


-- 
Konstantin = Osipov, Moscow, Russia, +7 903 626 22 = 32

= --Apple-Mail=_BC5DAC86-4D1A-4A42-81A9-712528AEA967--