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 957496FF9F; Tue, 5 Oct 2021 12:55:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 957496FF9F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1633427740; bh=lcVw5EHdS03dNZmgz3k59k9P1wsvgigd34VUxxWhOAI=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Y38IiHwvPAdLfQfDSZtN3CMSBbrm3b/6pT90rAPAZ6fXF7erUaQoyuyK2TGc2QOr4 QZ7S0bUdI+dc0nvxaTjWYBLaZhjNinvyo2VYRBGBIMQoNuQ4TB6WaBMwBNsP7Ct+Ex Ouap9ITo6c27UYuhCtasMaz106BGJq8zUL46BiIw= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [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 046DA6DB02 for ; Tue, 5 Oct 2021 12:55:39 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 046DA6DB02 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mXhAg-00005I-BL; Tue, 05 Oct 2021 12:55:38 +0300 Date: Tue, 5 Oct 2021 12:55:37 +0300 To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Message-ID: <20211005095537.GF55311@tarantool.org> References: <32c9fec9-30b6-f213-3a49-8772be433e99@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <32c9fec9-30b6-f213-3a49-8772be433e99@tarantool.org> X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD9064ADF4728AA0EE950704E1C1E1FED60C49BF516B31B232E182A05F538085040F96DC1A1553B2BD0ECEA5CEB7E99434857F8DEC8F477D1D31606A461B94D3CBC X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7798B95EC47D21699EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006373D58C44ED3182E498638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D88C32A177CFE64C382D21FBACDA4F8734117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC8883BAB8B32E402CA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751F6FD1C55BDD38FC3FD2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B66F6A3E018CF4DC80089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5644FACC9BDF45E1B92F85B46DA4A9140E61CF94C56C1117BD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75C4D20244F7083972410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D347130F804358653A64399C9544D89332DE0843BFD429DAE2F012F52FF81105AEC447E22C0BEE546751D7E09C32AA3244CCA62367E05CA11F16AB4FEEFFA5B9D5424AF4FAF06DA24FD729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojhAh8SZXECpA7k65/K+9gaw== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D1449C3A1EC89A78D04E2E68E7BE9F8B983D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v4 11/16] sql: refactor COUNT() function 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: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thank you for the review! My answer below. On Mon, Oct 04, 2021 at 11:53:50PM +0200, Vladislav Shpilevoy wrote: > Nicely done! > > On 01.10.2021 14:48, imeevma@tarantool.org wrote: > > Part of #4145 > > --- > > src/box/sql/func.c | 64 +++++++++++++++++++--------------------------- > > 1 file changed, 26 insertions(+), 38 deletions(-) > > > > diff --git a/src/box/sql/func.c b/src/box/sql/func.c > > index 94ec811ef..384c68be8 100644 > > --- a/src/box/sql/func.c > > +++ b/src/box/sql/func.c > > @@ -154,6 +154,29 @@ fin_avg(struct sql_context *ctx) > > ctx->is_aborted = true; > > } > > > > +/** Implementation of the COUNT() function. */ > > +static void > > +step_count(struct sql_context *ctx, int argc, struct Mem **argv) > > +{ > > + assert(argc == 0 || argc == 1); > > + if (mem_is_null(ctx->pMem)) > > + mem_set_uint(ctx->pMem, 0); > > Would be nice to have a 'begin' step for the aggregation > functions. This would allow to eliminate these 'if is null' > ifs in some step functions in favor of having +1 virtual 'begin' > call in the beginning. > > Do you think it would simplify/speed up things? If you agree, > could you please create a ticket for that? As 'good first issue' > even. > > If don't agree, then ignore this comment. I think this is a good idea, but I don't see a suitable way to implement it. The problem is that in case we receive NULL as an argument, we will have NULL in pMem/pOut after the first step, and we still have to call begin() again or check with 'if'. And there is no way to determine how much NULLs will there be.