[MDEV-17039] Query plan changes when we use GROUP BY optimization with optimizer_use_condition_selectivity=4 and use_stat_tables= PREFERABLY Created: 2018-08-23  Updated: 2018-09-19  Resolved: 2018-08-28

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.0.37, 10.1.36, 10.2.18, 10.3.10, 10.4.0

Type: Bug Priority: Major
Reporter: Varun Gupta (Inactive) Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
PartOf
is part of MDEV-15253 Default optimizer setting changes for... Closed

 Description   

MariaDB [test]> CREATE TABLE t1 (a INT, b INT, INDEX (a,b));
Query OK, 0 rows affected (0.02 sec)
 
MariaDB [test]> INSERT INTO t1 (a, b) VALUES (1,1), (1,2), (1,3), (1,4), (1,5),
    (2,2), (2,3), (2,1), (3,1), (4,1), (4,2), (4,3), (4,4), (4,5), (4,6);
Query OK, 15 rows affected (0.01 sec)
Records: 15  Duplicates: 0  Warnings: 0

Case 1:

MariaDB [test]> set @@optimizer_use_condition_selectivity=4;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [test]> set @@use_stat_tables= PREFERABLY;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [test]> explain  SELECT 1 FROM t1 AS t1_outer WHERE 
    -> a IN (SELECT max(b) FROM t1 GROUP BY a HAVING a < 2); 
+------+--------------+-------------+--------+---------------+--------------+---------+-----------------+------+--------------------------+
| id   | select_type  | table       | type   | possible_keys | key          | key_len | ref             | rows | Extra                    |
+------+--------------+-------------+--------+---------------+--------------+---------+-----------------+------+--------------------------+
|    1 | PRIMARY      | t1_outer    | index  | a             | a            | 10      | NULL            |   16 | Using where; Using index |
|    1 | PRIMARY      | <subquery2> | eq_ref | distinct_key  | distinct_key | 4       | test.t1_outer.a |    1 |                          |
|    2 | MATERIALIZED | t1          | range  | NULL          | a            | 5       | NULL            |    5 | Using index for group-by |
+------+--------------+-------------+--------+---------------+--------------+---------+-----------------+------+--------------------------+
3 rows in set (0.01 sec)

Case 2:

MariaDB [test]> set @@optimizer_use_condition_selectivity=1;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [test]> set @@use_stat_tables= NEVER;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [test]> explain  SELECT 1 FROM t1 AS t1_outer WHERE 
    -> a IN (SELECT max(b) FROM t1 GROUP BY a HAVING a < 2); 
+------+--------------+-------------+-------+---------------+------+---------+--------------------+------+--------------------------+
| id   | select_type  | table       | type  | possible_keys | key  | key_len | ref                | rows | Extra                    |
+------+--------------+-------------+-------+---------------+------+---------+--------------------+------+--------------------------+
|    1 | PRIMARY      | <subquery2> | ALL   | distinct_key  | NULL | NULL    | NULL               |    4 |                          |
|    1 | PRIMARY      | t1_outer    | ref   | a             | a    | 5       | <subquery2>.max(b) |    4 | Using index              |
|    2 | MATERIALIZED | t1          | range | NULL          | a    | 5       | NULL               |    4 | Using index for group-by |
+------+--------------+-------------+-------+---------------+------+---------+--------------------+------+--------------------------+
3 rows in set (0.00 sec)



 Comments   
Comment by Varun Gupta (Inactive) [ 2018-08-23 ]

* thread #2, stop reason = step over
    frame #0: 0x0000000100554e42 mysqld`best_access_path(join=0x0000625000024378, s=0x0000625000025fd0, remaining_tables=0, idx=0, disable_jbuf=<unavailable>, record_count=1, pos=0x00006250000264f8, loose_scan_pos=0x0000000000000004) at sql_select.cc:6278
   6275	        account here for range/index_merge access. Find out why this is so.
   6276	      */
   6277	      tmp= record_count *
-> 6278	        (s->quick->read_time +
   6279	         (s->found_records - rnd_records)/(double) TIME_FOR_COMPARE);
   6280	
   6281	      loose_scan_opt.check_range_access(join, idx, s->quick);
Target 0: (mysqld) stopped.
(lldb) p s->found_records
(ha_rows) $4 = 8
(lldb) p rnd_records
(double) $5 = 15

Here s->found_records has estimates from the GROUP BY optimization(loosescan)
while the rnd_records which we get through selectivity analysis does not take into account GROUP BY optimization

Comment by Varun Gupta (Inactive) [ 2018-08-23 ]

Patch
http://lists.askmonty.org/pipermail/commits/2018-August/012817.html

Comment by Sergei Petrunia [ 2018-08-26 ]

Review comments in the reply email. Ok to push after addressed.

Generated at Thu Feb 08 08:33:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.