diff options
author | Vicențiu Ciorbaru <vicentiu@mariadb.org> | 2017-02-14 14:02:29 +0200 |
---|---|---|
committer | Vicențiu Ciorbaru <vicentiu@mariadb.org> | 2017-02-15 14:09:27 +0200 |
commit | 9fe9fb68acd763ad3908c03d82d4de577d6f0c21 (patch) | |
tree | 2fdda1b80fbed14f7188085d8377d82a61b3f361 /sql/sql_window.cc | |
parent | a90066b1c7618f6d121eb7079c2939f21c6ad863 (diff) | |
download | mariadb-git-9fe9fb68acd763ad3908c03d82d4de577d6f0c21.tar.gz |
MDEV-10859: Wrong result of aggregate window function in query with HAVING and no ORDER BY
Window functions need to be computed after applying the HAVING clause.
An optimization that we have for regular, non-window function, cases is
to apply having only during sending of the rows to the client. This
allows rows that should be filtered from the temporary table used to
store aggregation results to be stored there.
This behaviour is undesireable for window functions, as we have to
compute window functions on the result-set after HAVING is applied.
Storing extra rows in the table leads to wrong values as the frame
bounds might capture those -to be filtered afterwards- rows.
Diffstat (limited to 'sql/sql_window.cc')
-rw-r--r-- | sql/sql_window.cc | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/sql/sql_window.cc b/sql/sql_window.cc index 37095ad78ca..2bdac89f293 100644 --- a/sql/sql_window.cc +++ b/sql/sql_window.cc @@ -2840,6 +2840,12 @@ bool Window_funcs_computation::setup(THD *thd, order_window_funcs_by_window_specs(window_funcs); SQL_SELECT *sel= NULL; + /* + If the tmp table is filtered during sorting + (ex: SELECT with HAVING && ORDER BY), we must make sure to keep the + filtering conditions when we perform sorting for window function + computation. + */ if (tab->filesort && tab->filesort->select) { sel= tab->filesort->select; |