[MDEV-8857] [Upstream too] EXPLAIN incorrectly shows Distinct for tables using join buffer Created: 2015-09-27  Updated: 2016-04-17  Resolved: 2016-04-17

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.0, 10.1
Fix Version/s: 10.2.0

Type: Bug Priority: Major
Reporter: Sergei Petrunia Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None


 Description   

EXPLAIN may show "Distinct" for tables that use join buffer. This is not a possible execution strategy, one can debug and confirm that Distinct optimization is not used in this case.

Copying from my report to upstream:

create table ten(a int);
 
insert into ten values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
 
 
 
create table twenty (a int, filler char(200), key(a));
 
insert into twenty select A.a + B.a* 10, 'AAAAAAAAAAAAAAAAAAAA' from ten A, ten B where B.a in (0,1);
 

MySQL [test]>  explain select A.a from ten A, twenty B where A.a+B.a> 0;
 
+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------------------------------------+
 
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                                                           |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------------------------------------+
 
|  1 | SIMPLE      | A     | ALL   | NULL          | NULL | NULL    | NULL |   10 | NULL                                                            |
 
|  1 | SIMPLE      | B     | index | NULL          | a    | 5       | NULL |   20 | Using where; Using index; Using join buffer (Block Nested Loop) |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------------------------------------+
 

MySQL [test]> explain select distinct A.a from ten A, twenty B where A.a+B.a> 0; 
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------------------------------------------+
 
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                                                                     |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------------------------------------------+
 
|  1 | SIMPLE      | A     | ALL   | NULL          | NULL | NULL    | NULL |   10 | Using temporary                                                           |
 
|  1 | SIMPLE      | B     | index | NULL          | a    | 5       | NULL |   20 | Using where; Using index; Distinct; Using join buffer (Block Nested Loop) |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------------------------------------------+

Look at the second query. It has "Distinct". I think this wrong. "Distinct"
doesn't work with "Using join buffer".

To make sure we are on the same page: "Distinct" in table B means that as soon
as we've got a match for current record in table A, we don't have to look for
any other matches. The query's SELECT list is "SELECT DISTINCT A.a", there is
no point to look for additional A.row-B.row pairs with the same A.row.

 Comments   
Comment by Sergei Petrunia [ 2015-09-27 ]

Quoting my comment for upstream:

You can see Distinct in action: put a breakpoint in end_write and end_send.
Then:

set optimizer_switch='block_nested_loop=off';
 
# Put a breakpoint in end_send
 
select A.a from ten A, twenty B where A.a+B.a> 0;
 
# observe that breakpoint was hit 200 times.
 

# Run EXPLAIN to be sure about what's going on:
 
MySQL [test]> explain select A.a from ten A, twenty B where A.a+B.a> 0;
 
+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+
 
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                    |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+
 
|  1 | SIMPLE      | A     | ALL   | NULL          | NULL | NULL    | NULL |   10 | NULL                     |
 
|  1 | SIMPLE      | B     | index | NULL          | a    | 5       | NULL |   20 | Using where; Using index |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

Then,

set optimizer_switch='block_nested_loop=off';
 
# Put a breakpoint in end_write 
select distinct A.a from ten A, twenty B where A.a+B.a> 0;
 
# Observe that breakpoint was hit 11 times.
 
# This is how Distinct optimization works.
 

# (just in case, let's check EXPLAIN: )
 
MySQL [test]> explain select distinct A.a from ten A, twenty B where A.a+B.a> 0;
 
+----+-------------+-------+-------+---------------+------+---------+------+------+------------------------------------+
 
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                              |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+------------------------------------+
 
|  1 | SIMPLE      | A     | ALL   | NULL          | NULL | NULL    | NULL |   10 | Using temporary                    |
 
|  1 | SIMPLE      | B     | index | NULL          | a    | 5       | NULL |   20 | Using where; Using index; Distinct |
 
+----+-------------+-------+-------+---------------+------+---------+------+------+------------------------------------+

Ok, now with "Using join buffer":

set optimizer_switch='block_nested_loop=on';

  1. Put a breakpoint in end_send
    select A.a from ten A, twenty B where A.a+B.a> 0;
  2. observe that breakpoint was hit 200 times.
  1. Put a breakpoint in end_write
    select distinct A.a from ten A, twenty B where A.a+B.a> 0;
  2. Observe that breakpoint was hit 200 times, again.

When one takes time to think about, it becomes obvious that "Distinct"
optimization cannot be used with Join buffering. And it is not used. But EXPLAIN shows it's used.

Comment by Sergei Petrunia [ 2015-09-27 ]

For the record: this was discovered when analyzing MDEV-7983.

Comment by Sergei Petrunia [ 2016-04-17 ]

This was fixed as part of MDEV-8646

Generated at Thu Feb 08 07:30:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.