[MDEV-6846] Test tokudb_mariadb.mdev6657 fails in buildbot (and outside) Created: 2014-10-06  Updated: 2014-10-10  Resolved: 2014-10-10

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: N/A
Fix Version/s: 10.1.1

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: buildbot, tests

Issue Links:
Relates
relates to MDEV-6657 Poor plan choice for ORDER BY key DES... Closed

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-amd64/builds/851/steps/test/logs/stdio

CURRENT_TEST: tokudb_mariadb.mdev6657
--- /usr/local/mariadb-10.1.1-linux-x86_64/mysql-test/plugin/tokudb/tokudb_mariadb/r/mdev6657.result	2014-10-06 11:54:56.000000000 +0300
+++ /usr/local/mariadb-10.1.1-linux-x86_64/mysql-test/plugin/tokudb/tokudb_mariadb/r/mdev6657.reject	2014-10-06 16:30:44.327828045 +0300
@@ -34,7 +34,7 @@
 where col1 <= 1410799999 
 order by col1 desc,col2 desc,col3 desc limit 1;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t3	range	PRIMARY,key1	PRIMARY	4	NULL	2001	Using where; Using index
+1	SIMPLE	t3	range	PRIMARY,key1	key1	4	NULL	2001	Using where; Using index
 # The same query but the constant is bigger. 
 # The query should use range(PRIMARY), not full index scan:
 explain 
@@ -43,5 +43,5 @@
 where col1 <= 1412199999 
 order by col1 desc, col2 desc, col3 desc limit 1;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t3	range	PRIMARY,key1	PRIMARY	4	NULL	15001	Using where; Using index
+1	SIMPLE	t3	range	PRIMARY,key1	key1	4	NULL	15001	Using where; Using index
 drop table t1,t2,t3;

I got the same failure while running the single test on my machine.



 Comments   
Comment by Sergei Petrunia [ 2014-10-10 ]

Debugging current 10.1 (=new)and 10.1 right after the fix for MDEV-6657 (=old), looking for
differences.

They start at test_if_skip_sort_order()/ test_if_order_by_key(idx=1) call.

  • in old code test_if_order_by_key() returns 0 (means' its not ordered)
  • new code returns -1 (means reverse ordered).

we have

   PRIMARY KEY (col1,col2,col3),
   KEY key1 (col1,col2) 
...
where col1 <= 1412199999 
order by 
   col1 desc, 
   col2 desc, 
   col3 desc limit 1;

indeed, "key1" produces the required ordering. Old code is unable to recognize
it, because it doesn't have this fix:

MDEV-6796: Unable to skip filesort when using implicit extended key
 
Re-work test_if_order_by_key() to work correctly for extended indexes.

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