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

  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