[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