[tarantool-patches] Re: [PATCH v2 4/8] sql: get rid of SQL_FUNC_COUNT flag
n.pettik
korablev at tarantool.org
Tue Aug 13 23:35:36 MSK 2019
> On 8 Aug 2019, at 17:50, Kirill Shcherbatov <kshcherbatov at tarantool.org> wrote:
>
> 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.
>
> 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’t it?
> and should be reworked in relation with introducing
> a uniform functions cache in further patches.
>
> 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.
>
> Needed for #2200, #4113, #2233
> ---
>
> - if ((agg_info->aFunc[0].pFunc->funcFlags & SQL_FUNC_COUNT) == 0)
> + if (agg_info->aFunc->pExpr->x.pList != NULL &&
> + agg_info->aFunc->pExpr->x.pList->nExpr > 0)
> return NULL;
Hm, this code works just by accident :) There’s no check
that function is really COUNT, but we are lucky enough
and there’s no other aggregate function which can take
empty list of arguments...
> if (expr->flags & EP_Distinct)
> return NULL;
> --
> 2.22.0
More information about the Tarantool-patches
mailing list