[MDEV-5107] Left Join Yields All Nulls Instead of Appropriate Matches Created: 2013-10-07 Updated: 2013-10-15 Resolved: 2013-10-15 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 10.0.4, 5.3.12, 5.5.33a |
| Fix Version/s: | 5.5.34, 10.0.6, 5.3.13 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jamie Jackson | Assignee: | Oleksandr Byelkin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | optimizer | ||
| Environment: |
All (Win 7 64-bit; Ubuntu 12.10 64-bit) |
||
| Attachments: |
|
| Description |
|
Querying the attached data with:
Yields: For comparison, results from MySQL 5.1.69:
Results from MariaDB 5.5.32:
Note: Switching
yields correct results. |
| Comments |
| Comment by Oleksandr Byelkin [ 2013-10-08 ] |
|
It looks like |
| Comment by Oleksandr Byelkin [ 2013-10-09 ] |
|
It is simplified test suite: CREATE TABLE `t1` ( INSERT INTO `t1` VALUES (11,NULL,13319),(12,NULL,NULL),(13,NULL,13319),(14,NULL,NULL),(15,NULL,13319),(16,NULL,NULL); CREATE TABLE `t2` ( INSERT INTO `t2` VALUES (78,'807702B6-C614-36DA-9EABA66ABE212B22'),(15,'C759EEC9-9A0F-D253-2DD3BEF19E43E960'),(16,'C759EEC9-9A0F-D253-2DD3BEF19E43E960'),(77,'E7441CB5-9035-D6C3-BBC9ABE6A3770B25'); CREATE TABLE `t3` ( CREATE TABLE `t4` ( INSERT INTO `t4` VALUES (18552,'9907E324-020E-5865-A0DAB0E3AE4969C6','!!!'),(18551,'95EB705A-C6DA-3C90-E87200E74B96434A','18551.pdf'); set @save_optimizer_switch=@@optimizer_switch; drop tables t1, t2, t3, t4; |
| Comment by Oleksandr Byelkin [ 2013-10-09 ] |
|
To find table on which we should check NULL Item_direct_view_ref::check_null_ref gets the left most real table of the VIEW or derived table (get_real_join_table()) and get unused table which probably do net update status correctly (if change order of the tables in the view or in the derived table bug will disappear). The problem now how to find correct table in the all leaf tables of the view or of the derived table. |
| Comment by Oleksandr Byelkin [ 2013-10-09 ] |
|
Above maybe wrong because mark_as_null_row was really called twice for both tables. |