From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Kirill Shcherbatov <kshcherbatov@tarantool.org>, Konstantin Osipov <kostja@tarantool.org> 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 [thread overview] Message-ID: <35C5E394-EC1A-421B-8868-F4451CC96DE1@tarantool.org> (raw) In-Reply-To: <20190514184106.GC5201@atlas> [-- Attachment #1: Type: text/plain, Size: 2391 bytes --] > On 14 May 2019, at 21:41, Konstantin Osipov <kostja@tarantool.org> wrote: > > * n.pettik <korablev@tarantool.org <mailto: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’t we simply do this: Sorry, I meant: "Why can’t we simply do this…" So this is suggestion how to fix redundant fields decoding. >> Add to ck_constraint array of used field numbers - >> that’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:{ >> int iTab = pExpr->iTable; >> int col = 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: >> >> … >> for (int i = 0; i < ck_field_count; ++i) { >> if (ck_fields[i] == col) >> return ck_fields[i]; >> } >> assert(0); >> >> When it’s time to run program, we go through array >> and assign only fields present there: >> >> … >> for (int i = 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 [-- Attachment #2: Type: text/html, Size: 11586 bytes --]
next prev parent reply other threads:[~2019-05-14 18:49 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-14 15:02 [tarantool-patches] " Kirill Shcherbatov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 1/3] schema: add new system space for CHECK constraints Kirill Shcherbatov 2019-05-14 18:29 ` [tarantool-patches] " Konstantin Osipov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 2/3] box: run check constraint tests on space alter Kirill Shcherbatov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 3/3] box: user-friendly interface to manage ck constraints Kirill Shcherbatov 2019-05-14 20:09 ` [tarantool-patches] " Konstantin Osipov 2019-05-14 17:00 ` [tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces Konstantin Osipov [not found] ` <FB4C0C9D-E56E-4FEF-A2C5-87AD8BF634F9@gmail.com> 2019-05-14 18:22 ` n.pettik 2019-05-14 18:41 ` Konstantin Osipov 2019-05-14 18:49 ` n.pettik [this message] 2019-05-15 8:37 ` Kirill Shcherbatov 2019-05-16 13:51 ` Kirill Shcherbatov 2019-05-19 16:02 ` Vladislav Shpilevoy
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=35C5E394-EC1A-421B-8868-F4451CC96DE1@tarantool.org \ --to=korablev@tarantool.org \ --cc=kostja@tarantool.org \ --cc=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces' \ /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