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 D7A5B2C023 for ; Tue, 14 May 2019 14:49:24 -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 HrhXhTVxyiIl for ; Tue, 14 May 2019 14:49:24 -0400 (EDT) Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 7018B2BFE7 for ; Tue, 14 May 2019 14:49:24 -0400 (EDT) From: "n.pettik" Message-Id: <35C5E394-EC1A-421B-8868-F4451CC96DE1@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3BF6858F-13F9-41F6-9559-2970F8A2A0D9" 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:49:21 +0300 In-Reply-To: <20190514184106.GC5201@atlas> References: <20190514170050.GB5201@atlas> <60C9520B-20B2-4944-B44E-99B6A3E454EB@tarantool.org> <20190514184106.GC5201@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: Kirill Shcherbatov , Konstantin Osipov --Apple-Mail=_3BF6858F-13F9-41F6-9559-2970F8A2A0D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 May 2019, at 21:41, Konstantin Osipov = wrote: >=20 > * n.pettik > = [19/05/14 21:26]: >>>> 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. >>=20 >> We can=E2=80=99t we simply do this: Sorry, I meant: "Why can=E2=80=99t we simply do this=E2=80=A6" So this is suggestion how to fix redundant fields decoding. >> 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. >>=20 >> Part of code responsible for CK code generation is: >>=20 >> 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; >> } >>=20 >>=20 >> So we have to pass that array to parsing context. >> Using that array code will look like this: >>=20 >> =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); >>=20 >> When it=E2=80=99s time to run program, we go through array >> and assign only fields present there: >>=20 >> =E2=80=A6 >> for (int i =3D 0; i < ck_field_count; ++i) { >> sql_bind_decode(&bind, ck_fields[i]) >> sql_bind_column(...) >> } >=20 > I believe I understand how it works now.=20 >=20 > What is the problem in fixing it? In scope of this patch set or a > different one is another issue. >=20 >=20 > --=20 > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 --Apple-Mail=_3BF6858F-13F9-41F6-9559-2970F8A2A0D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 May 2019, at 21:41, Konstantin Osipov <kostja@tarantool.org> wrote:

* n.pettik <korablev@tarantool.org> [19/05/14 21:26]:
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=99t we = simply do this:

Sorry, I meant:
"Why can=E2=80=99t we = simply do this=E2=80=A6"

So this is = suggestion how to fix redundant fields decoding.

Add = to ck_constraint array of used field numbers -
that=E2=80=99= s 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(...)
}

I believe I understand how it works now. 

What is the problem in fixing = it? In scope of this patch set or a
different one is another issue.


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

= --Apple-Mail=_3BF6858F-13F9-41F6-9559-2970F8A2A0D9--