diff options
author | Monty <monty@mariadb.org> | 2022-02-02 14:25:25 +0200 |
---|---|---|
committer | Monty <monty@mariadb.org> | 2022-02-08 14:32:29 +0200 |
commit | 38058c04a4fc021f381f8000e40ed23bd4fb8d75 (patch) | |
tree | 3f94cf20f203e68c3627ad2fdcf6d17f3ba5cde8 /sql/sql_test.h | |
parent | d314bd266491baf0954d13fa51dc22b730a6f4d1 (diff) | |
download | mariadb-git-38058c04a4fc021f381f8000e40ed23bd4fb8d75.tar.gz |
MDEV-26585 Wrong query results when `using index for group-by`
The problem was that "group_min_max optimization" does not work if
some aggregate functions, like COUNT(*), is used.
The function get_best_group_min_max() is using the join->sum_funcs
array to check which aggregate functions are used.
The bug was that aggregates in HAVING where not yet added to
join->sum_funcs at the time get_best_group_min_max() was called.
Fixed by populate join->sum_funcs already in prepare, which means that
all sum functions will be in join->sum_funcs in get_best_group_min_max().
A benefit of this approach is that we can remove several calls to
make_sum_func_list() from the code and simplify the function.
I removed some wrong setting of 'sort_and_group'.
This variable is set when alloc_group_fields() is called, as part
of allocating the cache needed by end_send_group() and does not need
to be set by other functions.
One problematic thing was that Spider is using *join->sum_funcs to detect
at which stage the optimizer is and do internal calculations of aggregate
functions. Updating join->sum_funcs early caused Spider to fail when trying
to find min/max values in opt_sum_query().
Fixed by temporarily resetting sum_funcs during opt_sum_query().
Reviewer: Sergei Petrunia
Diffstat (limited to 'sql/sql_test.h')
0 files changed, 0 insertions, 0 deletions