InnoDB's estimate for the index cardinality depends on a pseudo random
number generator (it picks up random pages to sample). After an
optimization that was made in r2625 the following EXPLAINs started
returning a different number of rows (3 instead of 4).

This patch adjusts the result file.

This patch cannot be proposed to MySQL because the failures occur only
in this tree and do not occur in the standard InnoDB 5.1. Furthermore,
the file index_merge2.inc is used by other engines too.

--- mysql-test/r/index_merge_innodb.result.orig	2008-09-30 18:32:13.000000000 +0300
+++ mysql-test/r/index_merge_innodb.result	2008-09-30 18:33:01.000000000 +0300
@@ -111,7 +111,7 @@
 explain select count(*) from t1 where
 key1a = 2 and key1b is null and  key2a = 2 and key2b is null;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t1	index_merge	i1,i2	i1,i2	10,10	NULL	4	Using intersect(i1,i2); Using where; Using index
+1	SIMPLE	t1	index_merge	i1,i2	i1,i2	10,10	NULL	3	Using intersect(i1,i2); Using where; Using index
 select count(*) from t1 where
 key1a = 2 and key1b is null and key2a = 2 and key2b is null;
 count(*)
@@ -119,7 +119,7 @@
 explain select count(*) from t1 where
 key1a = 2 and key1b is null and key3a = 2 and key3b is null;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t1	index_merge	i1,i3	i1,i3	10,10	NULL	4	Using intersect(i1,i3); Using where; Using index
+1	SIMPLE	t1	index_merge	i1,i3	i1,i3	10,10	NULL	3	Using intersect(i1,i3); Using where; Using index
 select count(*) from t1 where
 key1a = 2 and key1b is null and key3a = 2 and key3b is null;
 count(*)