From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id AB0046C7D3; Tue, 30 Mar 2021 02:03:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AB0046C7D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1617058997; bh=Gs0Ercq+FNasK5NmuK3UHxA+vucGdmIDnK3R+WjI4aA=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=JoihqXabqFXMuJlbo/p3QKlYzABEvgv4a4+whQWoA0gpfJlkGeCJF6DlHPMBPprYd QKJDitUSl5LrwQ/UurCkfkcTv240sFzZ9npeyfDidjG85bkTo/okfSbqf8EcfT4TI+ 5xlqbakKjqe3ksA4W8aye/AzWMqMT9qukR4j9jak= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 145C46BD01 for ; Tue, 30 Mar 2021 02:02:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 145C46BD01 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lR0tb-0008HL-9g; Tue, 30 Mar 2021 02:02:07 +0300 To: imeevma@tarantool.org, tsafin@tarantool.org Cc: tarantool-patches@dev.tarantool.org References: <0baa01ddd89e572df674bdb920d0616a4d465eda.1616491731.git.imeevma@gmail.com> Message-ID: <5d1f7bff-1148-40c6-c2e2-00559ff2138e@tarantool.org> Date: Tue, 30 Mar 2021 01:02:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <0baa01ddd89e572df674bdb920d0616a4d465eda.1616491731.git.imeevma@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9ED7173E37F4E3294DD38BE31D7797EF84C856624A09E4809182A05F53808504087F0F9A1D52613929453BC2C38397E86F04A67E3C2944B902DED7A9D51D4EAA7 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE721B3E54BB37EA0B4EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006379108F895B68B2FFD8638F802B75D45FF914D58D5BE9E6BC131B5C99E7648C95CE99938B3FD79E1DFCEC68750F9489E2A91D357FE6F84DAE7A471835C12D1D9774AD6D5ED66289B5259CC434672EE6371117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE7328B01A8D746D8839FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA71A620F70A64A45A98AA50765F790063735872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A5F4E2880E41139D8AF1582B73D75BB1BC255639A9CEAB416ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D341B5517184E88C1BDE6EDBE107F96504DFF9D86B03480D8CD1CC3B796EBA0EA70366BC53E167424731D7E09C32AA3244C88D984D018BC3775BB467BA80857B6277C0C08F7987826B9FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojljIiQOC84rRvALuH5aRJKg== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822A032194C995027E6331F4E58D726D5473841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v4 15/53] sql: rework vdbe_decode_msgpack_into_mem() X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thanks for the patch! See 3 comments below. On 23.03.2021 10:35, Mergen Imeev via Tarantool-patches wrote: > The original vdbe_decode_msgpack_into_mem() returns a MEM that contains > string and binary values as ephemeral. This patch renames this function > to vdbe_decode_msgpack_into_mem_ephemeral() and introduces new > vdbe_decode_msgpack_into_mem(), which returns a MEM that contains string > and binary values in newly allocated memory. > > This patch actually changes behavior in this case: 1. Changes how? I don't see any changes in the tests. > CREATE TABLE t1(m VARBINARY primary key); > INSERT INTO t1 VALUES(x'6178'), (x'6278'), (x'6379'); > SELECT count(*), substr(m,2,1) AS m FROM t1 GROUP BY m; > SELECT count(*), substr(m,2,1) AS mx FROM t1 GROUP BY mx; > > But it doesn't change behaviour for this: > > CREATE TABLE t2(m STRING primary key); > INSERT INTO t2 VALUES('ax'), ('bx'), ('cy'); > SELECT count(*), substr(m,2,1) AS m FROM t2 GROUP BY m; > SELECT count(*), substr(m,2,1) AS mx FROM t2 GROUP BY mx; > > Part of #5818 > Part of #5890 > --- > src/box/sql/mem.c | 16 +++++++++++++++- > src/box/sql/mem.h | 17 ++++++++++++++++- > src/box/sql/vdbe.c | 18 ------------------ > src/box/sql/vdbeaux.c | 2 +- > 4 files changed, 32 insertions(+), 21 deletions(-) > > diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c > index 3d42ac63c..a2316cc90 100644 > --- a/src/box/sql/mem.c > +++ b/src/box/sql/mem.c > @@ -2253,7 +2253,8 @@ sqlVdbeRecordCompareMsgpack(const void *key1, > } > > int > -vdbe_decode_msgpack_into_mem(const char *buf, struct Mem *mem, uint32_t *len) > +vdbe_decode_msgpack_into_ephemeral_mem(const char *buf, struct Mem *mem, > + uint32_t *len) 2. The function name is getting Java vibes. I propose to rename it to mem_from_mp_ephemeral() and mem_from_mp() correspondingly. They also should start taking the mem as a first argument. > { > const char *start_buf = buf; > switch (mp_typeof(*buf)) { > @@ -2354,6 +2355,19 @@ install_blob: > return 0; > } > > +int > +vdbe_decode_msgpack_into_mem(const char *buf, struct Mem *mem, uint32_t *len) > +{ > + if (vdbe_decode_msgpack_into_ephemeral_mem(buf, mem, len) != 0) > + return -1; > + if ((mem->flags & (MEM_Str | MEM_Blob)) != 0) { > + assert((mem->flags & MEM_Ephem) != 0); > + if (sqlVdbeMemGrow(mem, mem->n, 1) != 0) > + return -1; 3. Maybe it is worth adding a function like mem_materialize() or mem_make_writable() for that kind of work. > + } > + return 0; > +}