[tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces
n.pettik
korablev at tarantool.org
Tue May 14 21:49:21 MSK 2019
> On 14 May 2019, at 21:41, Konstantin Osipov <kostja at tarantool.org> wrote:
>
> * n.pettik <korablev at tarantool.org <mailto:korablev at tarantool.org>> [19/05/14 21:26]:
>>>> On 14 May 2019, at 20:00, Konstantin Osipov <kostja at tarantool.org> wrote:
>>>>
>>>> * Kirill Shcherbatov <kshcherbatov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20190514/16c76470/attachment.html>
More information about the Tarantool-patches
mailing list