Bug#33838439: ExtractValue not working properly with COUNT

If a derived table is implicitly grouped and if there is a condition
that could be pushed down to this table, it needs to be
pushed to the having clause of that derived table. However if the
condition does not have expressions involving columns from a table and
yet evaluates to a non const item, it is currently pushed to the
where clause. For an implicitly grouped query, if this where clause
evaluates to false, aggregation function results in a NULL. However if
it is evaluated as a having condition it will result in an empty set.
So the solution is to push conditions to the having clause instead of
where clause as the result of the where clause influences the result
of the aggregation function.

Change-Id: I948892cbe0390f1fdfddaa94661ff460da935967

Author: Chaithra Gopalareddy

mysql-test/r/derived_condition_pushdown.result

@@ -1922,3 +1922,18 @@ JOIN information_schema.table_constraints b
 USING (table_schema)
 WHERE b.constraint_type = 'FOREIGN KEY';
 TABLE_NAME
+#
+# Bug#33838439: ExtractValue not working properly with COUNT
+#
+CREATE TABLE t1 (f1 INTEGER);
+SET @a = 0;
+EXPLAIN SELECT COUNT(*) FROM (SELECT SUM(f1) FROM t1) as dt WHERE @a = 1;
+id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
+1	PRIMARY	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	no matching row in const table
+2	DERIVED	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	Impossible HAVING
+Warnings:
+Note	1003	/* select#1 */ select count(0) AS `COUNT(*)` from (/* select#2 */ select sum(`test`.`t1`.`f1`) AS `SUM(f1)` from `test`.`t1` having false) `dt`
+SELECT COUNT(*) FROM (SELECT SUM(f1) FROM t1) as dt WHERE @a = 1;
+COUNT(*)
+0
+DROP TABLE t1;

mysql-test/t/derived_condition_pushdown.test

@@ -1195,3 +1195,15 @@ FROM information_schema.key_column_usage a
 WHERE b.constraint_type = 'FOREIGN KEY';
 
 #End of test for Bug#33791802
+
+--echo #
+--echo # Bug#33838439: ExtractValue not working properly with COUNT
+--echo #
+
+CREATE TABLE t1 (f1 INTEGER);
+
+SET @a = 0;
+EXPLAIN SELECT COUNT(*) FROM (SELECT SUM(f1) FROM t1) as dt WHERE @a = 1;
+SELECT COUNT(*) FROM (SELECT SUM(f1) FROM t1) as dt WHERE @a = 1;
+
+DROP TABLE t1;

sql/sql_derived.cc

@@ -1209,19 +1209,31 @@ bool Condition_pushdown::push_past_window_functions() {
 }
 
 /**
-  Try to push the condition past GROUP BY into the WHERE clause of the
-  derived table. Check that all columns in the condition are present as
-  grouping columns of the current query block. If not, the condition
-  cannot be pushed to the WHERE clause. It will have to stay in HAVING
-  clause.
+  Try to push the condition or parts of the condition past GROUP BY into
+  the WHERE clause of the derived table.
+  1. For a non-grouped query, the condition is moved to the WHERE clause.
+  2. For an implicitly grouped query, condition remains in the HAVING
+     clause in order to preserve semantics.
+  3. For a query with ROLLUP, the condition will remain in the HAVING
+     clause because ROLLUP might add NULL values to the grouping columns.
+  4. For other grouped queries, predicates involving grouping columns
+     can be moved to the WHERE clause. Predicates that reference aggregate
+     functions remain in HAVING clause.
+  We perform the same checks for a non-standard compliant GROUP BY too.
+  If a window function's PARTITION BY clause is on non-grouping columns
+  (possible if GROUP BY is non-standard compliant or when these columns
+   are functionally dependednt on the grouping columns) then the condition
+  will stay in HAVING clause.
 */
 bool Condition_pushdown::push_past_group_by() {
   if (!m_query_block->is_grouped()) {
     m_where_cond = m_having_cond;
     m_having_cond = nullptr;
     return false;
   }
-  if (m_query_block->olap == ROLLUP_TYPE) return false;
+  if (m_query_block->is_implicitly_grouped() ||
+      m_query_block->olap == ROLLUP_TYPE)
+    return false;
   m_checking_purpose = CHECK_FOR_WHERE;
   Opt_trace_object step_wrapper(trace, "pushing_past_group_by");