summaryrefslogtreecommitdiff
path: root/mysql-test/r/subselect_sj_jcl6.result
Commit message (Collapse)AuthorAgeFilesLines
* Create 'main' test directory and move 't' and 'r' thereMichael Widenius2018-03-291-3422/+0
|
* Merge remote-tracking branch 'origin/10.2' into bb-10.2-extAlexander Barkov2017-06-151-1/+94
|\
| * Merge 10.1 into 10.2Marko Mäkelä2017-05-231-1/+94
| |\
| | * Merge 10.0 into 10.1Marko Mäkelä2017-05-231-0/+54
| | |\
| | | * Merge branch '5.5' into 10.0mariadb-10.0.31Sergei Golubchik2017-05-201-0/+54
| | | |\
| | | | * Fixed the bug mdev-12817/mdev-12820.Igor Babaev2017-05-171-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is a correction of the patch for bug mdev-12670. With the current code handling semi-joins the following must be taken into account. Conversion of an IN subquery predicate into semi-join has to be blocked if the predicate occurs: (a) in the ON expression of an outer join (b) in the ON expression of an inner join embedded directly or indirectly in the inner nest of an outer join. The patch for mdev-12670 blocked conversion to semi-joins only in the case (a), but not in the case (b). This patch blocks the conversion in both cases.
| | * | | Merge 10.0 into 10.1Marko Mäkelä2017-05-201-1/+40
| | |\ \ \ | | | |/ / | | | | | | | | | | | | | | | | | | | | Significantly reduce the amount of InnoDB, XtraDB and Mariabackup code changes by defining pfs_os_file_t as something that is transparently compatible with os_file_t.
| | | * | Merge remote-tracking branch 'origin/5.5' into 10.0Vicențiu Ciorbaru2017-05-171-1/+40
| | | |\ \ | | | | |/
| | | | * Fixed the bugs mdev-12670 and mdev-12675.Igor Babaev2017-05-091-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that blocked conversion of a IN subselect pedicate to a semi-join if it occurred in the ON expression of an outer join did not do it correctly. As a result, the conversion was blocked for IN subselect predicates encountered in ON expressions of INNER joins or in WHERE conditions of mergeable views / derived tables. This patch fixes this problem.
* | | | | Merge tag 'mariadb-10.2.6' into bb-10.2-extAlexander Barkov2017-05-261-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.1' into 10.2Sergei Golubchik2017-05-091-1/+1
| |\ \ \ \ | | |/ / / | | | | | | | | | | | | | | | Revert commit db0917f68f, because the fix for MDEV-12696 is coming from 5.5 and 10.1 in this merge.
| | * | | Merge branch '10.0' 10.1Sergei Golubchik2017-04-281-1/+1
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.0Sergei Golubchik2017-04-211-1/+1
| | | |\ \ | | | | |/
| | | | * Fixed the bug mdev-12429 and its duplicates mdev-12145 and mdev-9886.Igor Babaev2017-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also fixed a wrong result for a test case for mdev-7691 (the alternative one). The test cases for all these bug have materialized semi-joins used inside dependent sub-queries. The patch actually reverts the change inroduced by Monty in 2003. It looks like this change is not valid anymore after the implementation of semi-joins. Adjusted output from EXPLAIN for many other test cases.
* | | | | MDEV-10141: Add support for INTERSECT (and common parts for EXCEPT)Oleksandr Byelkin2017-03-141-4/+4
|/ / / / | | | | | | | | | | | | MDEV-10140: Add support for EXCEPT
* | | | Item::print(): remove redundant parenthesesSergei Golubchik2016-12-121-20/+20
| | | | | | | | | | | | | | | | | | | | by introducing new Item::precedence() method and using it to decide whether parentheses are required
* | | | MDEV-6720 - enable connection log in mysqltest by defaultSergey Vojtovich2016-03-311-0/+4
|/ / /
* | | Merge branch '10.0' into 10.1Sergei Golubchik2016-02-231-0/+65
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.0Sergei Golubchik2016-02-151-0/+65
| |\ \ | | |/
| | * MDEV-6859: scalar subqueries in a comparison produced unexpected resultSergei Petrunia2016-02-091-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When one evaluates row-based comparison like (X, Y) = (A,B), one should first call bring_value() for the Item that returns row value. If you don't do that and just attempt to read values of X and Y, you get stale values. Semi-join/Materialization can take a row-based comparison apart and make ref access from it. In that case, we need to call bring_value() to get the index lookup components.
| | * MDEV-7823: Server crashes in next_depth_first_tab on nested IN clauses with ↵Sergei Petrunia2016-02-091-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SQ inside Consider a query with subquery in form t.key=(select ...). Suppose, the parent query uses this equality for ref access. It will attempt to evaluate the subquery in get_best_combination(), right before the join->join_tab[...] array is filled. The problem was that subquery optimization will attempt to look at parent's join->join_tab to check how many times subquery will be executed (and crash). Fixed by not doing that when the subquery is constant (non-constant subqueries are only be evaluated during join execution, so they are not affected)
* | | MDEV-8852 Implicit or explicit CAST from MAX(string) to INT,DOUBLE,DECIMAL ↵Alexander Barkov2015-09-281-0/+6
| | | | | | | | | | | | does not produce warnings
* | | MDEV-8806 Numeric CAST produce different warnings for strings literals vs ↵Alexander Barkov2015-09-251-0/+3
| | | | | | | | | | | | functions
* | | MDEV-6066: Merge new defaults from 5.6 and 5.7 (defaults changed, QC can be ↵Oleksandr Byelkin2015-09-041-4/+1
|/ / | | | | | | stopped with no-zero size)
* | Merge branch '5.5' into 10.0Sergei Golubchik2015-05-041-0/+9
|\ \ | |/
| * MDEV-7911: crash in Item_cond::eval_not_null_tablesSergei Petrunia2015-04-211-0/+9
| | | | | | | | | | | | convert_subq_to_sj() must check the results of in_equality->fix_fields() call. It can fail in a meaningful way when e.g. we're trying to compare columns with incompatible collations.
* | Fixed bug mdev-6071.Igor Babaev2014-06-101-0/+2
| | | | | | | | | | | | | | | | The method JOIN_CACHE::init may fail (return 1) if some conditions on the used join buffer is not satisfied. For example it fails if join_buffer_size is greater than join_buffer_space_limit. The conditions should be checked when running the EXPLAIN command for the query. That's why the method JOIN_CACHE::init has to be called for EXPLAIN commands as well.
* | MDEV-6153 Trivial Lintian errors in MariaDB sources: spelling errors and ↵Sergei Golubchik2014-05-131-2/+2
| | | | | | | | wrong executable bits
* | 5.5 mergeSergei Golubchik2014-02-251-0/+16
|\ \ | |/
| * 5.3 mergeSergei Golubchik2014-02-221-0/+16
| |\
| | * MDEV-5581: Server crashes in in JOIN::prepare on 2nd execution of PS with ↵Sergey Petrunya2014-02-151-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | materialization+semijoin - The problem was that JOIN::prepare() tried to set TABLE::maybe_null for a table in join. Non-merged semi-join tables 1) are present as join's base tables on second EXECUTE, but 2) do not yet have a TABLE object. Worked around the problem by putting mixed_implicit_grouping into JOIN object, and then passing it to JTBM tables in setup_jtbm_semi_joins().
* | | 5.5 mergeSergei Golubchik2014-02-011-2/+2
|\ \ \ | |/ /
| * | MDEV-5349: Test main.subselect_sj_jcl6 fails sporadically due to ↵Sergey Petrunya2013-12-301-2/+2
| | | | | | | | | | | | | | | | | | insufficient ordering - Add --sorted_result to the query
* | | 5.5 mergeSergei Golubchik2013-11-231-0/+50
|\ \ \ | |/ /
| * | MDEV-5059: Wrong result (missing row) wih semijoin, join_cache_level > 2, ↵Sergey Petrunya2013-11-211-6/+23
| | | | | | | | | | | | | | | | | | LEFT JOIN, ORDER BY - Added testcase
| * | MDEV-5161: Wrong result (missing rows) with semijoin, LEFT JOIN, ORDER BY, ↵Sergey Petrunya2013-11-211-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constant table - Don't pull out a table out of a semi-join if it is on the inner side of an outer join. - Make join->sort_by_table= get_sort_by_table(...) call after const table detection is done. That way, the value of join->sort_by_table will match the actual execution. Which will allow the code in setup_semijoin_dups_elimination() (search for "Make sure that possible sorting of rows from the head table is not to be employed." to see that "Using filesort" is going to be used together with Duplicate Elimination ( and change it to Using temporary + Using filesort)
* | | MDEV-5123 Remove duplicated conditions pushed both to join_tab->select_cond ↵timour@askmonty.org2013-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and join_tab->cache_select->cond for blocked joins. BNL and BNLH joins pre-filter the records from a joined table via JOIN_TAB::cache_select->cond. There is no need to re-evaluate the same conditions via JOIN_TAB::select_cond. This patch removes the duplicated conditions from the top-level conjuncts of each pushed condition. The added "Using where" in few EXPLAINs is due to taking into account tab->cache_select->cond in addition to tab->select_cond in JOIN::save_explain_data_intern.
* | | MDEV-3798: [SHOW] EXPLAIN UPDATE/DELETESergey Petrunya2013-10-151-3/+3
|\ \ \ | |/ / |/| | | | | - Merge with 10.0-base
| * | [SHOW] EXPLAIN UPDATE/DELETE, code re-structuringSergey Petrunya2013-08-241-3/+3
| |\ \ | | | | | | | | | | | | - Merge with current 10.0-base
| | * \ [SHOW] EXPLAIN UPDATE/DELETE, code re-structuringSergey Petrunya2013-06-271-3/+3
| | |\ \ | | | | | | | | | | | | | | | | | | | | - Merge with 10.0-base
| | | * | [SHOW] EXPLAIN UPDATE/DELETE, code re-structuringSergey Petrunya2013-06-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part 2 of: - Pass more tests - select with subselects is now shown with type=PRIMARY where it used to be (incorrectly) 'SIMPLE'
* | | | | Fixed bug mdev-4420.Igor Babaev2013-08-231-1/+1
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code of JOIN::optimize that performed substitutions for the best equal field in all ref items did not take into account that a multiple equality could contain the result of the single-value subquery if the subquery is inexpensive. This code was corrected. Also made necessary corresponding corrections in the code of make_join_select().
* | | | mdev-4173: Wrong result (extra row) with semijoin=on, joins in outer query, ↵Sergey Petrunya2013-07-161-0/+36
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | LEFT JOIN in the subquery Apply the patch from Patryk Pomykalski: - create_internal_tmp_table_from_heap() will now return information whether the last row that we tried to write was a duplicate row. (mysql-5.6 also has this change)
* | | MDEV-4071: Valgrind warnings 'Invalid read' in ↵Sergey Petrunya2013-05-041-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | subselect_engine::calc_const_tables with ... - Call tmp_having->update_used_tables() *before* we have call JOIN::cleanup(). Making the call after join::cleanup() is not allowed, because subquery predicate items walk parent join's JOIN_TAB structures. Which can be invalidated by JOIN::cleanup().
* | | MDEV-389: Wrong result (missing row) with semijoin, join_cache_level>4 ...Sergey Petrunya2013-05-041-0/+18
|/ / | | | | | | - Added testcase
* | Merge 5.3 -> 5.5Sergey Petrunya2013-04-031-0/+10
|\ \ | |/
| * MDEV-4335: Unexpected results when selecting on information_schemaSergey Petrunya2013-03-291-0/+10
| | | | | | | | | | - When converting a subquery to a semi-join, propagate OPTION_SCHEMA_TABLE.
* | 5.3->5.5 mergeSergei Golubchik2013-02-281-14/+14
|\ \ | |/
| * Fixed bug mdev-3913.Igor Babaev2013-02-201-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wrong result set returned by the left join query from the bug test case happened due to several inconsistencies and bugs of the legacy mysql code. The bug test case uses an execution plan that employs a scan of a materialized IN subquery from the WHERE condition. When materializing such an IN- subquery the optimizer injects additional equalities into the WHERE clause. These equalities express the constraints imposed by the subquery predicate. The injected equality of the query in the test case happens to belong to the same equality class, and a new equality imposing a condition on the rows of the materialized subquery is inferred from this class. Simultaneously the multiple equality is added to the ON expression of the LEFT JOIN used in the main query. The inferred equality of the form f1=f2 is taken into account when optimizing the scan of the rows the temporary table that is the result of the subquery materialization: only the values of the field f1 are read from the table into the record buffer. Meanwhile the inferred equality is removed from the WHERE conditions altogether as a constraint on the fields of the temporary table that has been used when filling this table. This equality is supposed to be removed from the ON expression when the multiple equalities of the ON expression are converted into an optimal set of equality predicates. It supposed to be removed from the ON expression as an equality inferred from only equalities of the WHERE condition. Yet, it did not happened due to the following bug in the code. Erroneously the code tried to build multiple equality for ON expression twice: the first time, when it called optimize_cond() for the WHERE condition, the second time, when it called this function for the HAVING condition. When executing optimize_con() for the WHERE condition a reference to the multiple equality of the WHERE condition is set in the multiple equality of the ON expression. This reference would allow later to convert multiple equalities of the ON expression into equality predicates. However the the second call of build_equal_items() for the ON expression that happened when optimize_cond() was called for the HAVING condition reset this reference to NULL. This bug fix blocks calling build_equal_items() for ON expressions for the second time. In general, it will be beneficial for many queries as it removes from ON expressions any equalities that are to be checked for the WHERE condition. The patch also fixes two bugs in the list manipulation operations and a bug in the function substitute_for_best_equal_field() that resulted in passing wrong reference to the multiple equalities of where conditions when processing multiple equalities of ON expressions. The code of substitute_for_best_equal_field() and the code the helper function eliminate_item_equal() were also streamlined and cleaned up. Now the conversion of the multiple equalities into an optimal set of equality predicates first produces the sequence of the all equalities processing multiple equalities one by one, and, only after this, it inserts the equalities at the beginning of the other conditions. The multiple changes in the output of EXPLAIN EXTENDED are mainly the result of this streamlining, but in some cases is the result of the removal of unneeded equalities from ON expressions. In some test cases this removal were reflected in the output of EXPLAIN resulted in disappearance of “Using where” in some rows of the execution plans.
* | 5.3 mergeSergei Golubchik2013-01-281-0/+15
|\ \ | |/
View Lorry Controller Status