Bug #58050 | BIT_OR and BIT_XOR return incorrect results when semijoin=on | ||
---|---|---|---|
Submitted: | 8 Nov 2010 12:33 | Modified: | 1 Dec 2010 16:36 |
Reporter: | SaiKumar V | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S2 (Serious) |
Version: | mysql-next-mr-opt-backporting,5.5 | OS: | Linux (RedHat x64) |
Assigned to: | Georgi Kodinov | CPU Architecture: | Any |
Tags: | bit_or, bit_xor, join, regression, semijoin |
[8 Nov 2010 12:33]
SaiKumar V
[10 Nov 2010 10:43]
Roy Lyseng
It appears that this is a general problem with joining and bit_or() and bit_xor(). Here is a join query that is fairly equivalent to the above semijoin query with BIT_OR(): select b.* from b join bb on b.col_varchar_nokey=bb.col_varchar_key and b.pk=1; It returns an empty result set. Then we apply a BIT_OR aggregation to this query: select bit_or(b.col_int_nokey) from b join bb on b.col_varchar_nokey=bb.col_varchar_key and b.pk=1; +-------------------------+ | bit_or(b.col_int_nokey) | +-------------------------+ | 1 | +-------------------------+ 1 row in set (0.00 sec) According to the manual, this should return 0 if there are no matching rows. Another join query that is fairly equivalent to the above semijoin query with BIT_XOR(): SELECT c.* FROM c JOIN cc ON c.col_varchar_nokey=cc.col_varchar_key AND c.pk = 8; It returns an empty result set. Then we apply a BIT_XOR aggregation to this query: SELECT BIT_XOR(c.pk) FROM c JOIN cc ON c.col_varchar_nokey=cc.col_varchar_key AND c.pk = 8; +---------------+ | BIT_XOR(c.pk) | +---------------+ | 8 | +---------------+ 1 row in set (0.00 sec) According to the manual, this should return 0 if there are no matching rows. Thus it appears that this is a general join problem and not a semijoin problem.
[10 Nov 2010 10:49]
Roy Lyseng
The problem with the join query appears in 5.5 as well as in next-mr, but it does not occur in 5.1
[16 Nov 2010 8:53]
Roy Lyseng
Simplified test case for bug#58050 and bug#57954: CREATE TABLE t1 ( pk int PRIMARY KEY, b int, c int ) ENGINE=InnoDB; INSERT INTO t1 VALUES(1, 1, 1); CREATE TABLE t2 ( pk int PRIMARY KEY, b int, c int ) ENGINE=InnoDB; INSERT INTO t2 VALUES (1, 1, NULL); SELECT t1.* FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1; SELECT BIT_OR(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1; SELECT BIT_AND(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1; SELECT BIT_XOR(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1; DROP TABLE t1, t2;
[16 Nov 2010 8:53]
Roy Lyseng
Running bzrfind on the 5.5 tree gives this source for regression: revno: 2875.8.8 revision-id: joro@sun.com-20090928072125-cbx5j0v2oe5d7av6 parent: alik@sun.com-20090925094758-j4rfs37jf3v482t9 committer: Georgi Kodinov <joro@sun.com> branch nick: mysql-wl3220-next-mr timestamp: Mon 2009-09-28 10:21:25 +0300 message: Ported WL#3220 to mysql-next-mr.
[1 Dec 2010 16:36]
Georgi Kodinov
Fixed by the fix for bug #57954