From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5B01921460 for ; Tue, 13 Aug 2019 16:35:39 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN3wkbBSa0rT for ; Tue, 13 Aug 2019 16:35:39 -0400 (EDT) Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 1AA162057A for ; Tue, 13 Aug 2019 16:35:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: [tarantool-patches] Re: [PATCH v2 4/8] sql: get rid of SQL_FUNC_COUNT flag From: "n.pettik" In-Reply-To: <2f18c9df1d818a222f2fb3005d13bd59228d4698.1565275469.git.kshcherbatov@tarantool.org> Date: Tue, 13 Aug 2019 23:35:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2f18c9df1d818a222f2fb3005d13bd59228d4698.1565275469.git.kshcherbatov@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Kirill Shcherbatov > On 8 Aug 2019, at 17:50, Kirill Shcherbatov = wrote: >=20 > Tarantool's SQL engine generates a different VDBE bytecode > for ..COUNT(*).. and ..COUNT(fieldname).. operations: > the first one produces a lightweight OP_Count operation that uses > native mechanism to report the count of record in index while > the second one pessimistically opens a space read iterator and > uses Count aggregate function. >=20 > A helper routine is_simple_count decides whether such > optimisation is correct. Using SQL_FUNC_COUNT flag to mark a > dummy (non-functional) Why do you consider it to be non-functional? > function entry with 0 arguments is a bad practice Why? Please, support this with arguments. As I understand, the real reason is that we are striving to remove function overloading, isn=E2=80=99t it? > and should be reworked in relation with introducing > a uniform functions cache in further patches. >=20 > Therefore SQL_FUNC_COUNT flag test in is_simple_count helper > was replaced with more straightforward test with manually looking > for count of function arguments passed. >=20 > Needed for #2200, #4113, #2233 > --- >=20 > - if ((agg_info->aFunc[0].pFunc->funcFlags & SQL_FUNC_COUNT) =3D=3D = 0) > + if (agg_info->aFunc->pExpr->x.pList !=3D NULL && > + agg_info->aFunc->pExpr->x.pList->nExpr > 0) > return NULL; Hm, this code works just by accident :) There=E2=80=99s no check that function is really COUNT, but we are lucky enough and there=E2=80=99s no other aggregate function which can take empty list of arguments... > if (expr->flags & EP_Distinct) > return NULL; > --=20 > 2.22.0