From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 dev.tarantool.org (Postfix) with ESMTPS id 61DE6446439 for ; Thu, 24 Sep 2020 23:45:28 +0300 (MSK) References: <18754f111764a630acf8285dcd8c4b5cfd2a254e.1599220118.git.imeevma@gmail.com> <6147fe3a-fd68-53b3-3a95-a7321de79183@tarantool.org> <1600750986.926093408@f173.i.mail.ru> <1600752315.389449454@f362.i.mail.ru> From: Vladislav Shpilevoy Message-ID: Date: Thu, 24 Sep 2020 22:45:26 +0200 MIME-Version: 1.0 In-Reply-To: <1600752315.389449454@f362.i.mail.ru> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH v1 1/1] sql: enable autoindex optimization List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?0JzQtdGA0LPQtdC9INCY0LzQtdC10LI=?= Cc: Mergen Imeev , tarantool-patches@dev.tarantool.org Спасибо за ответы! > > + int cursor, int reg_out, int reg_eph) > > +{ > > + assert(reg_out != 0); > > + struct Vdbe *v = parse->pVdbe; > > + int col_cnt = idx_def->key_def->part_count; > > + int reg_base = sqlGetTempRange(parse, col_cnt + 1); > > + for (int j = 0; j < col_cnt; j++) { > > + uint32_t tabl_col = idx_def->key_def->parts[j].fieldno; > > + sqlVdbeAddOp3(v, OP_Column, cursor, tabl_col, reg_base + j); > > + /* > > + * If the column type is NUMBER but the number > > + * is an integer, then it might be stored in the > > + * table as an integer (using a compact > > + * representation) then converted to REAL by an > > + * OP_Realify opcode. But we are getting > > + * ready to store this value back into an index, > > + * where it should be converted by to INTEGER > > + * again. So omit the OP_Realify opcode if > > + * it is present > > + */ > > + sqlVdbeDeletePriorOpcode(v, OP_Realify); > > + } > > + sqlVdbeAddOp2(v, OP_NextIdEphemeral, reg_eph, reg_base + col_cnt); > > + sqlVdbeAddOp3(v, OP_MakeRecord, reg_base, col_cnt + 1, reg_out); > > + > > + sqlReleaseTempRange(parse, reg_base, col_cnt); > > + return reg_base; > > +} > > + > > /* > > - * Generate code to construct the Index object for an automatic index > > - * and to set up the WhereLevel object pLevel so that the code generator > > - * makes use of the automatic index. > > + * Generate code to construct the ephemeral space that contains used in query > > + * fields of one of the tables. The index of this ephemeral space will be known > > + * as an "automatic index". Also, this functions set up the WhereLevel object > > + * pLevel so that the code generator makes use of the automatic index. > > */ > > static void > > constructAutomaticIndex(Parse * pParse, /* The parsing context */ > > @@ -801,9 +852,11 @@ constructAutomaticIndex(Parse * pParse, /* The parsing context */ > > n = 0; > > idxCols = 0; > > uint32_t size = sizeof(struct key_part_def) * nKeyCol; > > - struct key_part_def *part_def = malloc(size); > > + struct region *region = &fiber()->gc; > > + size_t used = region_used(region); > > + struct key_part_def *part_def = region_alloc(region, size); > > Это раздолбает с ASANом из-за отсутствия выравнивания. Нужен region_alloc_array. > > Исправлю, но мне казалочь, что это временый объект и его выравнивание нигде не проверяется. Временный или нет - это не важно. Если эта память используется, значит делается доступ по адресу, который вернулся из аллока. Выровнено доложно быть абсолтюно все. Если ты используешь память как struct key_part_def, значит память должна быть выровнена по alignof(struct key_part_def). Можно не выравнивать только PACKED структуры и байтовые массивы типа строк, где доступ побайтовый (выравнивание = 1). Проверок на выровненность действительно нет в обычных сборках. Но есть на сборке с асаном - он генерирует их во время компиляции, хоть в коде ты их и не видишь. Еще могут быть на некоторых процах, где доступ по невыровненному адресу может крешнуть.