--source include/have_debug_sync.inc

--echo #
--echo # WL#6986 : Make switching of index due to order by limit cost based
--echo #

--echo # Testcase for Bug#16522053

CREATE TABLE t1 (
  pk INT PRIMARY KEY AUTO_INCREMENT,
  i INT,
  j INT,
  INDEX (i),
  INDEX (j)
);

INSERT INTO t1 (i,j) VALUES (1,1);

let $1=7;
set @d=1;
while ($1)
{
  eval INSERT INTO t1 (i,j) SELECT i+@d, j+@d from t1;
  eval set @d=@d*2;
  dec $1;
}

ANALYZE TABLE t1;

let $query= SELECT * FROM t1
            WHERE i<100 AND j<10
            ORDER BY i LIMIT 5;
eval EXPLAIN $query;
eval $query;
DROP TABLE t1;

CREATE TABLE t0 (
  i0 INTEGER NOT NULL
);

INSERT INTO t0 VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);

CREATE TABLE t1 (
  pk INTEGER PRIMARY KEY,
  i1 INTEGER NOT NULL,
  i2 INTEGER NOT NULL,
  INDEX k1 (i1),
  INDEX k2 (i1,i2)
) ENGINE=InnoDB;

INSERT INTO t1
SELECT a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0,
       (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 1000,
       (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 1000
FROM t0 AS a0, t0 AS a1;

CREATE TABLE t2 (
  pk INTEGER PRIMARY KEY,
  i1 INTEGER NOT NULL,
  INDEX k1 (i1)
) ENGINE=InnoDB;

INSERT INTO t2
SELECT a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0,
              (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 500
  FROM t0 AS a0, t0 AS a1;

ANALYZE TABLE t1,t2;

--echo # Query should use index to optimize the ORDER BY LIMIT

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 and t1.i1 > 2
ORDER BY t1.i1 LIMIT 2;

eval EXPLAIN $query;

--echo # Query should not make the switch to use index to
--echo # optimize ORDER BY LIMIT. So should be using filesort

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 and t1.i1 > 2
ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
--partially_sorted_result 1
eval $query;

--echo # Changing range condition on i1 should make
--echo # key on i1 get picked to give the order

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 and t1.i1 > 800
ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
eval $query;

--echo # Use range condition only on pk to see if switch
--echo # happens just for ORDER BY LIMIT
--echo # Should not happen unless range results in too
--echo # many records

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
--partially_sorted_result 1
--replace_result 9091 9090  # These two records can both be chosen from t2.
eval $query;

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 1000 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
eval $query;

--echo # check if switch happens when the index for order 
--echo # by is non-covering

let query=
SELECT t1.i1,t1.i2 FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1 
WHERE t1.pk > 100 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
eval $query;

--echo # Reduce the fanout for table t2 and check
--echo # that index for order by is not choosen

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 and t2.pk = 100 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
eval $query;

--echo # Increase the fanout to see if index gets choosen
--echo # for order by for which range scan was choosen
--echo # earlier

INSERT INTO t2
SELECT a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0 + 1,
              (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 500
  FROM t0 AS a0, t0 AS a1;

ANALYZE TABLE t2;

let query=
SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i1=t2.i1
WHERE t1.pk > 7000 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
--partially_sorted_result 1
--replace_result 9091 9090  # These two records can both be chosen from t2.
eval $query;

--echo # Check if the index for order by is used when
--echo # force index is done on order by

let query=
SELECT * FROM t1 FORCE INDEX FOR ORDER BY (k2) STRAIGHT_JOIN t2 ON
t1.i1=t2.i1 WHERE t1.pk > 7000 ORDER BY t1.i1 LIMIT 5;

eval EXPLAIN $query;
--partially_sorted_result 1
--replace_result 9091 9090  # These two records can both be chosen from t2.
eval $query;

DROP TABLE t0, t1, t2;

--echo #
--echo # Bug #26483909: INCORRECT BEHAVIOR FOR QUERY WITH DISTINCT
--echo #                and ORDER BY ... LIMIT.
--echo #

CREATE TABLE t1 (
  pk int(11) NOT NULL,
  col_int int(11),
  col_varchar_key varchar(20),
  PRIMARY KEY (pk),
  KEY col_varchar_key (col_varchar_key),
  KEY col_varchar_key_2 (col_varchar_key(5))
);

# Note: The optimizer is free to pick either one of the rows with
# col_int=3, so they need to sort the same on col_varchar_key.
INSERT INTO t1 VALUES (1,2,'t'), (2,5,'efqsdksj'),
       (3,NULL,'fqsdksjijcs'),(4,8,'qsdksjijc'),
       (5,40,NULL),(6,3,'dkz'),(7,2,NULL),
       (8,3,'dks'),(9,0,'ksjijcsz'),
       (10,84,'sjijcszxwbjj');

let query1=
SELECT DISTINCT col_int
FROM t1
WHERE col_varchar_key <> 'c'
   OR col_varchar_key > 'w'
ORDER BY col_varchar_key
LIMIT 100;

ANALYZE TABLE t1;
SET @@SESSION.sql_mode='NO_ENGINE_SUBSTITUTION';
eval EXPLAIN $query1;
--skip_if_hypergraph
eval $query1;

DROP TABLE t1;

--echo #
--echo # Bug#29487181 INCORRECT 'ROWS' AND 'FILTERED' ESTIMATE IN
--echo #              'ORDER BY ... LIMIT .' QUERIES
--echo #

CREATE TABLE t1 (
  col_int_unique INT DEFAULT NULL,
  col_int_key INT DEFAULT NULL,
  UNIQUE KEY col_int_unique (col_int_unique),
  KEY col_int_key (col_int_key)
);

INSERT INTO t1 VALUES (49,49), (9,7), (0,1), (2,42);

CREATE TABLE t2 (
  col_int_unique INT DEFAULT NULL,
  pk INT NOT NULL,
  PRIMARY KEY (pk),
  UNIQUE KEY col_int_unique (col_int_unique)
);

INSERT INTO t2 VALUES (2,8), (5,2), (6,1);
ANALYZE TABLE t1,t2;

EXPLAIN
SELECT STRAIGHT_JOIN t1.col_int_key AS field1
FROM t1 JOIN t2
  ON t2.pk = t1.col_int_unique OR
     t2.col_int_unique = t1.col_int_key
ORDER BY field1 LIMIT 2;

DROP TABLE t1,t2;

--echo #
--echo # Bug#30348211: DANGEROUS OPTIMIZATION RECONSIDERING_ACCESS_PATHS_FOR_
--echo #               INDEX_ORDERING
--echo #

CREATE TABLE t (id BIGINT NOT NULL, other_id BIGINT NOT NULL,
 covered_column VARCHAR(50) NOT NULL, non_covered_column VARCHAR(50) NOT NULL,
 PRIMARY KEY (id),
 INDEX index_other_id_covered_column (other_id, covered_column));

let $n = 10;
while ($n)
{
  eval INSERT INTO t (id, other_id, covered_column, non_covered_column)
       VALUES ($n, $n, '$n', '$n');
  dec $n;
}

SET
  optimizer_trace = "enabled=on",
  optimizer_trace_max_mem_size = 1000000,
  end_markers_in_json = ON;

#echo "With prefer_ordering_index=on, ordering index will be picked."
#echo "The original plan is discarded and a new one using ordering index "
#echo "is picked."
SET optimizer_switch = "prefer_ordering_index=on";
ANALYZE TABLE t;
EXPLAIN SELECT non_covered_column FROM t WHERE other_id > 3 ORDER BY id ASC LIMIT 2;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

#echo "With prefer_ordering_index=off, ordering index should not be picked"
SET optimizer_switch = "prefer_ordering_index=off";
EXPLAIN SELECT non_covered_column FROM t WHERE other_id > 3 ORDER BY id ASC LIMIT 2;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_0 FROM information_schema.optimizer_trace;

#echo "With prefer_ordering_index=default, ordering index should be picked"
SET optimizer_switch = default;
EXPLAIN SELECT non_covered_column FROM t WHERE other_id > 3 ORDER BY id ASC LIMIT 2;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

#echo "If an order by index is forced, plan will be to pick ordering index even if"
#echo "prefer_ordering_index is switched off"
SET optimizer_switch = "prefer_ordering_index=on";
EXPLAIN SELECT /*+ ORDER_INDEX(t PRIMARY) */ non_covered_column FROM t WHERE other_id > 3 ORDER BY id ASC LIMIT 2;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

SET optimizer_switch = "prefer_ordering_index=off";
EXPLAIN SELECT /*+ ORDER_INDEX(t PRIMARY) */ non_covered_column FROM t WHERE other_id > 3 ORDER BY id ASC LIMIT 2;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

#Insert some more data for group by
let $n = 10;
while ($n)
{
  eval INSERT INTO t (id, other_id, covered_column, non_covered_column)
       VALUES ($n+1+10, $n, '$n', '$n');
  dec $n;
}

#echo "With prefer_ordering_index=on, ordering index will be picked."
#echo "The original plan is discarded and a new one using ordering index "
#echo "is picked."
SET optimizer_switch = "prefer_ordering_index=on";
ANALYZE TABLE t;
EXPLAIN SELECT non_covered_column FROM t WHERE id > 8 GROUP BY other_id LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

#echo "With prefer_ordering_index=off, ordering index should not be picked"
SET optimizer_switch = "prefer_ordering_index=off";
EXPLAIN SELECT non_covered_column FROM t WHERE id > 8 GROUP BY other_id LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_0 FROM information_schema.optimizer_trace;

#echo "With prefer_ordering_index=default, ordering index should be picked"
SET optimizer_switch = default;
EXPLAIN SELECT non_covered_column FROM t WHERE id > 8 GROUP BY id LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

#echo "If a group by index is forced, plan will be to pick ordering index even if"
#echo "prefer_ordering_index is switched off"
SET optimizer_switch = "prefer_ordering_index=on";
EXPLAIN SELECT /*+ GROUP_INDEX(t index_other_id_covered_column) */ non_covered_column FROM t WHERE id > 8 GROUP BY other_id LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

SET optimizer_switch = "prefer_ordering_index=off";
EXPLAIN SELECT /*+ GROUP_INDEX(t index_other_id_covered_column) */ non_covered_column FROM t WHERE id > 8 GROUP BY other_id LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

DROP TABLE t;

--echo # Bug#32897503: Prepared statement performance slower with prefer
--echo #               ordering_index optimization
--echo # Bug#32897525: Prepared statement doesn't seem to use index extensions
--echo #               / extended_keys

CREATE TABLE p (
  pid int unsigned NOT NULL AUTO_INCREMENT,
  cid int unsigned NOT NULL,
  pl char(255) DEFAULT '',
  PRIMARY KEY (pid),
  KEY cid (cid)
);
INSERT INTO p (cid) VALUES (1), (2), (3), (4), (5), (6), (7), (8);
INSERT INTO p (cid) SELECT 1 FROM p;
INSERT INTO p (cid) SELECT 2 FROM p;
INSERT INTO p (cid) SELECT 3 FROM p;
INSERT INTO p (cid) SELECT 4 FROM p;
INSERT INTO p (cid) SELECT 5 FROM p;
INSERT INTO p (cid) SELECT 4 FROM p;
ANALYZE TABLE p;

let $q = SELECT pid, cid, pl FROM p WHERE cid = 4 ORDER BY pid DESC LIMIT 1;
let $p = SELECT pid, cid, pl FROM p WHERE cid = ? ORDER BY pid DESC LIMIT 1;
eval $q;
eval EXPLAIN $q;
eval PREPARE ps FROM "$p";
eval PREPARE pse FROM "EXPLAIN $p";

SET @client_id = 4;
EXECUTE pse USING @client_id;
EXECUTE ps USING @client_id;

DEALLOCATE PREPARE ps;
DEALLOCATE PREPARE pse;

SET @@optimizer_switch="prefer_ordering_index=off";

eval PREPARE ps FROM "$p";
eval PREPARE pse FROM "EXPLAIN $p";

EXECUTE pse USING @client_id;
EXECUTE ps USING @client_id;

DEALLOCATE PREPARE ps;
DEALLOCATE PREPARE pse;

DROP TABLE p;

SET optimizer_switch = DEFAULT;

--echo #
--echo # Bug#33066458: TEST_IF_SKIP_SORT_ORDER: ASSERTION `SELECT_LIMIT > 0' FAILED.
--echo #

CREATE TABLE t (x INTEGER PRIMARY KEY, y INTEGER);
INSERT INTO t VALUES (1, 2), (2, 3), (3, 4);
SELECT * FROM t ORDER BY x LIMIT 18446744073709551614;
DROP TABLE t;

--echo #
--echo # Bug#34291261: The result of query plan is different between 5.7 and 8.0
--echo #

CREATE TABLE test (
a bigint NOT NULL AUTO_INCREMENT,
b int not null,
c date NOT NULL,
d int NOT NULL,
PRIMARY KEY (a),
KEY ix_ordered_date (c,a)
);

DELIMITER $$;
CREATE PROCEDURE insertProc(input_date varchar(10))
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE (i <= 1000)
    DO
        INSERT INTO test VALUE (0, 0, input_date, 0);
        SET i = i + 1;
    END WHILE;
END$$
DELIMITER ;$$

CALL insertProc('2022-06-09');
CALL insertProc('2022-06-10');
CALL insertProc('2022-06-13');
analyze table test;

EXPLAIN SELECT * FROM test  WHERE c = '2022-06-13' AND a > 222 ORDER BY c, a LIMIT 10;

DROP PROCEDURE insertProc;
DROP TABLE test;

--echo #
--echo # Bug#34306497 - Low limit heuristic used unnecessarily with descending scans
--echo #

CREATE TABLE t1 (f1 INTEGER, f2 INTEGER, PRIMARY KEY (f1), KEY(f2, f1));

INSERT INTO t1 (
WITH RECURSIVE
a(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM a WHERE i < 9 ),
b(i) AS (SELECT x.i + y.i * 10 + z.i * 100 FROM a x, a y, a z)
SELECT b.i, b.i %2 FROM b ORDER BY i);

ANALYZE TABLE t1;

let query =
SELECT * FROM t1 WHERE f2 = 1 AND f1 <= 100 ORDER BY f1 DESC LIMIT 1;

eval EXPLAIN $query;
eval $query;

CREATE TABLE t2 (
 f1 INTEGER,
 f2 INTEGER,
 f3 INTEGER,
 f4 INTEGER,
 f5 INTEGER,
PRIMARY KEY (f1), KEY(f2,f3,f4,f5,f1));

INSERT INTO t2 (
WITH RECURSIVE a (i) AS (SELECT 0 UNION ALL SELECT i+1 FROM a WHERE i < 9 ),
b (i) AS (SELECT x.i + y.i * 10 + z.i * 100 FROM a x, a y, a z)
SELECT b.i, b.i%2, b.i%3, b.i%4, b.i%5 FROM b ORDER BY i);

ANALYZE TABLE t2;

let query =
SELECT * FROM t2
WHERE f3 = 1 AND f2 = 1 AND f4 = 3 AND f5 IN(2,3) ORDER BY f4 DESC LIMIT 1;
eval EXPLAIN $query;
--skip_if_hypergraph  # Different plan (elided ORDER BY) gives different result.
eval $query;

let query =
SELECT * FROM t2
WHERE f2 = 1 AND f3 = 2 AND f4 = 3 AND f5 IN(2,3) ORDER BY f3,f4 DESC LIMIT 1;
eval EXPLAIN $query;
eval $query;

let query =
SELECT * FROM t2
WHERE f2 = 1 AND f3 > 1 AND f4 = 3 AND f5 IN(2,3) ORDER BY f2,f3 DESC LIMIT 1;
eval EXPLAIN $query;
eval $query;

let query =
SELECT * FROM t2
WHERE f2 = 1 AND f3 > 1 AND f4 = 3 ORDER BY f2,f3,f5 DESC LIMIT 1;
eval EXPLAIN $query;
eval $query;

let query =
SELECT * FROM t2
WHERE f2 = 1 AND f3 > 1 AND f4 = 3 ORDER BY f2 DESC ,f3 DESC ,f5 DESC LIMIT 1;
eval EXPLAIN $query;
eval $query;

DROP TABLE t1,t2;

--echo #
--echo # Bug#35930969 MDS offloads to HW based on Incorrect Costings
--echo #              from Optimizer
--echo #
CREATE TABLE t1(id INT AUTO_INCREMENT,
                c1 VARCHAR(10), c2 VARCHAR(10), c3 VARCHAR(10),
                PRIMARY KEY(id)) SECONDARY_ENGINE MOCK;
INSERT INTO t1 (c1, c2, c3) values ('132456','456789','789123'),
                                  ('132456','456789','789123'),
                                  ('132456','456789','789123'),
                                  ('132456','456789','789123'),
                                  ('132456','456789','789123');
INSERT INTO t1(c1,c2,c3) SELECT t1.c1, t1.c2, t1.c3
  from t1, t1 as t11, t1 as t12, t1 as t13, t1 as t14;
ANALYZE TABLE t1;

let query =SELECT * FROM t1 ORDER BY id LIMIT 10;
--skip_if_hypergraph  # Depends on the query plan.
eval EXPLAIN FORMAT=Tree $query;
eval $query;
--skip_if_hypergraph  # Depends on the query plan.
SHOW SESSION STATUS LIKE '%cost%';

let query =SELECT * FROM t1 FORCE INDEX(PRIMARY) ORDER BY id LIMIT 10;
--skip_if_hypergraph  # Depends on the query plan.
eval EXPLAIN FORMAT=Tree $query;
eval $query;
--skip_if_hypergraph  # Depends on the query plan.
SHOW SESSION STATUS LIKE '%cost%';

let query =SELECT * FROM t1 use index() ORDER BY id LIMIT 10;
--skip_if_hypergraph  # Depends on the query plan.
eval EXPLAIN FORMAT=Tree $query;
eval $query;
--skip_if_hypergraph  # Depends on the query plan.
SHOW SESSION STATUS LIKE '%cost%';

let query =SELECT * FROM t1 WHERE c1 != 'asd' ORDER BY id LIMIT 10;
--skip_if_hypergraph  # Depends on the query plan.
eval EXPLAIN FORMAT=Tree $query;
eval $query;
--skip_if_hypergraph  # Depends on the query plan.
SHOW SESSION STATUS LIKE '%cost%';

DROP TABLE t1;


--echo # Bug#36213938: QEP regression with prefer_ordering_index=off
--echo #

CREATE TABLE t0 (
  i0 INTEGER NOT NULL
) ENGINE=InnoDB;
INSERT INTO t0 VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);

CREATE TABLE t1 (
 i1 INTEGER NOT NULL,
 i2 INTEGER NOT NULL,
 index k1 (i2)) ENGINE=InnoDB;
INSERT INTO t1
SELECT a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0,
       (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 1000
FROM t0 AS a0, t0 AS a1;

CREATE TABLE t2 (
  pk INTEGER PRIMARY KEY,
  i1 INTEGER NOT NULL,
  i2 INTEGER NOT NULL,
  INDEX k1 (i1)
) ENGINE=InnoDB;
INSERT INTO t2
SELECT a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0,
              (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 500,
              (a0.i0 + 10*a1.i0 + 100*a0.i0 + 1000*a1.i0) % 500
  FROM t0 AS a0, t0 AS a1;

ANALYZE TABLE t0,t1,t2;

--echo # Even when prefer_ordering_index is off, ordering index is picked
--echo # if possible when optimizer's original plan was to do a table scan.
SET optimizer_switch = "prefer_ordering_index=off";
EXPLAIN SELECT i2 FROM t2 ORDER BY pk LIMIT 1;
--skip_if_hypergraph  # Does not output the same optimizer trace.
SELECT (trace LIKE '%"plan_changed": true%') AS should_be_1 FROM information_schema.optimizer_trace;

--echo # Verify that when prefer ordering index is off and if the current plan
--echo # is to do a table scan, a recheck of the index usage does happen if
--echo # limit is specified in the query.
SET @@GLOBAL.DEBUG= '+d,prefer_ordering_index_check';

--connect (con1, localhost, root,,)
SET optimizer_switch = "prefer_ordering_index=off";
--send EXPLAIN SELECT * FROM t1 STRAIGHT_JOIN t2 ON t1.i2=t2.i1 WHERE t1.i1 > 7000 and t1.i2 > 0 ORDER BY t1.i2 LIMIT 1;
--sleep 1

# Verify that the index usage recheck function is called
--connection default
--let $using_hypergraph = `SELECT FIND_IN_SET('hypergraph_optimizer=on', @@optimizer_switch)`
if ($using_hypergraph) {
  --echo <ignored hypergraph optimizer error:  Depends on the query plan>
}
if (!$using_hypergraph) {
  --let $wait_condition= SELECT COUNT(*)=1 FROM performance_schema.threads WHERE NAME = "thread/sql/one_connection" AND PROCESSLIST_INFO LIKE "EXPLAIN SELECT * FROM t1%" AND PROCESSLIST_STATE = "preparing" ;
  --source include/wait_condition.inc
}

# Continue execution
SET DEBUG_SYNC= "now SIGNAL signal.prefer_ordering_index_check_continue";

--connection con1
--reap
--disconnect con1

# cleanup
--connection default
SET @@GLOBAL.DEBUG= '-d,prefer_ordering_index_check';
SET optimizer_switch = DEFAULT;
drop table t0, t1, t2;