--- m/r/compress.result	2013-07-22 17:03:39.000000000 +0400

+++ r/compress.result	2014-03-03 13:58:10.071341000 +0400

@@ -1506,17 +1509,17 @@

 50	11

 select count(*),min(fld4),max(fld4),sum(fld1),avg(fld1),std(fld1),variance(fld1) from t2 where companynr = 34 and fld4<>"";

 count(*)	min(fld4)	max(fld4)	sum(fld1)	avg(fld1)	std(fld1)	variance(fld1)

-70	absentee	vest	17788966	254128.0857	3272.5939722090234	10709871.306938833

+70	absentee	vest	17788966	254128.0857	3272.5940	10709871.3069

 explain extended select count(*),min(fld4),max(fld4),sum(fld1),avg(fld1),std(fld1),variance(fld1) from t2 where companynr = 34 and fld4<>"";

 id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra

 1	SIMPLE	t2	ALL	NULL	NULL	NULL	NULL	1199	100.00	Using where

 Warnings:

-Note	1003	/* select#1 */ select count(0) AS `count(*)`,min(`test`.`t2`.`fld4`) AS `min(fld4)`,max(`test`.`t2`.`fld4`) AS `max(fld4)`,sum(`test`.`t2`.`fld1`) AS `sum(fld1)`,avg(`test`.`t2`.`fld1`) AS `avg(fld1)`,std(`test`.`t2`.`fld1`) AS `std(fld1)`,variance(`test`.`t2`.`fld1`) AS `variance(fld1)` from `test`.`t2` where ((`test`.`t2`.`companynr` = 34) and (`test`.`t2`.`fld4` <> ''))

+Note	1003	select count(0) AS `count(*)`,min(`test`.`t2`.`fld4`) AS `min(fld4)`,max(`test`.`t2`.`fld4`) AS `max(fld4)`,sum(`test`.`t2`.`fld1`) AS `sum(fld1)`,avg(`test`.`t2`.`fld1`) AS `avg(fld1)`,std(`test`.`t2`.`fld1`) AS `std(fld1)`,variance(`test`.`t2`.`fld1`) AS `variance(fld1)` from `test`.`t2` where ((`test`.`t2`.`companynr` = 34) and (`test`.`t2`.`fld4` <> ''))

 select companynr,count(*),min(fld4),max(fld4),sum(fld1),avg(fld1),std(fld1),variance(fld1) from t2 group by companynr limit 3;

 companynr	count(*)	min(fld4)	max(fld4)	sum(fld1)	avg(fld1)	std(fld1)	variance(fld1)

-00	82	Anthony	windmills	10355753	126289.6707	115550.97568479746	13352027981.708656

-29	95	abut	wetness	14473298	152350.5053	8368.547956641249	70032594.90260443

-34	70	absentee	vest	17788966	254128.0857	3272.5939722090234	10709871.306938833

+00	82	Anthony	windmills	10355753	126289.6707	115550.9757	13352027981.7087

+29	95	abut	wetness	14473298	152350.5053	8368.5480	70032594.9026

+34	70	absentee	vest	17788966	254128.0857	3272.5940	10709871.3069

 select companynr,t2nr,count(price),sum(price),min(price),max(price),avg(price) from t3 where companynr = 37 group by companynr,t2nr limit 10;

 companynr	t2nr	count(price)	sum(price)	min(price)	max(price)	avg(price)

 37	1	1	5987435	5987435	5987435	5987435.0000

revno: 3690.68.30

committer: Oystein Grovlen <oystein.grovlen@oracle.com>

branch nick: mysql-trunk

timestamp: Wed 2012-06-20 12:37:14 +0200

message:

  Bug#11766758: MATERIALIZATION=ON/OFF LEADS TO DIFFERENT RESULT SET

  WHEN USING IN & VAR_POP

  This bug is caused by the fact that number of decimals in VAR_POP

  result, was calculated as the number of decimals in the argument

  (here int => 0) plus 4.

  Hence, in the example in the bug report, 3.5556 is stored in t2.X.

  When materialization is off, result of inner query is compared using

  Arg_comparator::compare_real_fixed() which takes number of decimals into

  account.

  When inner query is materialized, no truncation happens and the materialized

  column contains 3.555555555...

  The IN-expression is evaluated by doing hash-lookup into the materialized

  table, and since no record matches 3.5556, the result set is empty.

  According to the SQL standard the result of VAR_POP should be a

  floating point number. Hence, the result should not be truncated to

  a certain number of decimals.  This patch changes VAR_POP() and similar

  functions (VAR_SAMP(), VARIANCE(), STD(), STDDEV_POP(), STDDEV_SAMP(), and

  STDDEV())

  By changing this, results for these functions will never be truncated

  Hence, materialization should no longer give a different value from

  what is normally returned to users.