summaryrefslogtreecommitdiff
path: root/sql/sql_select.h
diff options
context:
space:
mode:
authorOlav Sandstaa <olav.sandstaa@oracle.com>2013-01-14 10:58:17 +0100
committerOlav Sandstaa <olav.sandstaa@oracle.com>2013-01-14 10:58:17 +0100
commite810f7f4eb3f094d158d902804df5ffb1cc2cc7d (patch)
tree8adba45a682be430a99b46d270546ebd17dfdf35 /sql/sql_select.h
parent18a9945c5bd7055ac7ee3ef2103d2087a10fe06a (diff)
downloadmariadb-git-e810f7f4eb3f094d158d902804df5ffb1cc2cc7d.tar.gz
Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY
WITH A VARIABLE AND ORDER BY Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX This is a fix for a regression introduced by Bug#12667154: Bug#12667154 attempted to fix a performance problem with subqueries that did filesort. For doing filesort, the optimizer creates a quick select object to use when building the sort index. This quick select object was deleted after the first call to create_sort_index(). Thus, for queries where the subquery was executed multiple times, the quick object was only used for the first execution. For all later executions of the subquery, filesort used a complete table scan for building the sort index. The fix for Bug#12667154 tried to fix this by not deleting the quick object after the first execution of create_sort_index() so that it would be re-used for building the sort index by the following executions of the subquery. This regression introduced in Bug#12667154 is that due to not deleting the quick select object after building the sort index, the quick object could in some cases be used also during the second phase of the execution of the subquery instead of using the created sort index. This caused wrong results to be returned. The fix for this issue is to delete the reference to the select object after it has been used in create_sort_index(). In this way the select and quick objects will not be available when doing the second phase of the execution of the select operation. To ensure that the select object can be re-used for the following executions of the subquery we make a copy of the select pointer. This is used for restoring the select object after the select operation is completed.
Diffstat (limited to 'sql/sql_select.h')
-rw-r--r--sql/sql_select.h16
1 files changed, 15 insertions, 1 deletions
diff --git a/sql/sql_select.h b/sql/sql_select.h
index c4f5dcba115..6732eb354d6 100644
--- a/sql/sql_select.h
+++ b/sql/sql_select.h
@@ -1,7 +1,7 @@
#ifndef SQL_SELECT_INCLUDED
#define SQL_SELECT_INCLUDED
-/* Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
+/* Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -160,6 +160,20 @@ typedef struct st_join_table {
TABLE *table;
KEYUSE *keyuse; /**< pointer to first used key */
SQL_SELECT *select;
+ /**
+ When doing filesort, the select object is used for building the
+ sort index. After the sort index is built, the pointer to the
+ select object is set to NULL to avoid that it is used when reading
+ the result records (@see create_sort_index()). For subqueries that
+ do filesort and that are executed multiple times, the pointer to
+ the select object must be restored before the next execution both
+ to ensure that the select object is used and to be able to cleanup
+ the select object after the final execution of the subquery. In
+ order to be able to restore the pointer to the select object, it
+ is saved in saved_select in create_sort_index() and restored in
+ JOIN::exec() after the main select is done.
+ */
+ SQL_SELECT *saved_select;
COND *select_cond;
QUICK_SELECT_I *quick;
Item **on_expr_ref; /**< pointer to the associated on expression */